What configuration items do you track for proper configuration management? [closed]

[Primarily Unix/Linux bias, I don't work on Windows systems :-)]

Anything that, once modified, alters the state of the running system needs to be tracked. Configuration must be stored in a repository that supports full change history, for example Git or Subversion, and it must be deployed in an automated manner such as with Opscode's Chef or Reductive Labs' Puppet.

A few examples of items that alter the state of the system:

• Installed package / patch versions.
• Deployed applications, application libraries.
• Administrative and application users.
• Hardware configuration and device drivers/modules.
• Scheduled maintenance jobs (cron on Unix/Linux).
• Services and components that are monitored by external tools.

Such tracking needs to be done with automated tools that provide sufficient logging for auditing changes. A software repository history will show, uh, the history of changes in the configuration files stored in said repository. In a declarative configuration tool like Chef or Puppet, each config file represents a set of resources such as users, packages or services, and the repository history will indicate changes in these.

From an application perspective, it is critical to document

• OS and patch level
• Which layered products are installed and which patches have been applied
• Which custom and / or third party products and libraries are installed including version
• Where to lay your hands on install source for said custom / third party items
• Product keys / SN's for all of the above
• Application level server configuration (ie- web, mail, etc)
• A contact list if there is a separate development team responsible at the application level
• Backup configuration

Note - in response to romandas' comment in the question, I know that's not exactly one item, but I consider the overall document one item in this case

For windows you shouldn't need to "track" patch levels of the OS as that can be queried at any time via WMI. If you are following change management you can do a global query before and after a change to verify the results of an OS patch. (make sure the MSI provider is installed)

Driver updates should be tracked (wmi can be used to query them but it's not worth the effort to try to catch them all) Software application updates should be kept in the CMDB but (except for initially) should come from change management If you really wanted to track registry changes set a group policy to enable file and object access and choose which keys to audit (http://support.microsoft.com/kb/324739). This isn't for a CMDB but will allow you to track who is making changes.

So that's what folks typically want to track in a CMDB and why it's sometimes not a good idea so what should go into a CMDB. The answer is it depends. An ITIL defined CMDB may or may not care about machine configs unless that particular machine config pertains to a service. ACMDB might also contain an asset tracking solution (for things like hardware config location and warranty info) but is more about relationships of a particular Configuration Item to other CI. Relationships include things like "is responsible for", "is connected to", "depends on" and (more difficult but in many cases more important) "required for SLA tier_". In short, record what's required to recreate the service - not the server.

For example. If email was the service I'd list things like:

Hardware: 64 bit CPU, 3gb of ram (based on # of users on @today) 7gb of space for server install, 100 gb of storage for exchange dbs and recovery (based on usage as of @today), dvd rom drive.

Software: Server 2003 R2, Exchange 2007 SP2, MPIO drivers for the SAN

etc...

CMDBs are not typically for server admin usage. Admins will be far happier with an asset management solution.