Using Auto-discovery Tools with Configuration Management Database (CMDB)

Auto-discovery tools refer to a set of tools that collects data on a network and records any changes made to the assets.  For example, HP’s Network Node Manager is able to discover all equipment connected to a TCP/IP network using the Simple Network Management Protocol (SNMP). Desktop management tools may be able to collect information about Windows-based devices using interfaces like Microsoft’s Windows Management Interface (WMI). In any case, the auto-discovery function is just one of the many functions of these tools. You will not probably buy these tools just for this function but if you have tools with such capabilities, why not use them to support Configuration Management? So when and how to use such tools?

During the Identification phase of the Configuration Management process where you need to populate data into our new CMDB, you will need to capture relevant information of the assets and Configuration Items. Auto-discovery tools are useful to get an initial inventory list of the assets or Configuration Items (CI) in your IT environment.  They can also capture relevant attributes of the asset or CI that you need. Do not load the data from the auto-discovery tools into the CMDB right away.

The auto-discovery tools should be able to produce a report, spreadsheet or CSV file with the information that you need for your CMDB. In any case, you may still cleanse or transform the data before loading them into the CMDB.  Different tools may produce different or conflicting information and some reformatting may be needed. Cleansing and transformation is best done manually and may need some consultation with the CI owners to validate conflicting data or information produced by the tools. Once you are happy with the data, do the CMDB loading. Your CMDB tool would typically offer a feature or interfaces for reading the data off a spreadsheet or CSV file for loading purpose.

Some tools users or vendors may advocate that the auto-discovery tools be closely linked to the CMDB and daily updates of the output from the tools into the CMDB be done during the normal day to day operations or Monitoring phase of the Configuration Management process.  This is NOT a good idea. What happens when an unauthorised change happens? The auto-discovery tool will just pick up the new unauthorised asset and the information gets updated into the CMDB. Not a good thing since the CMDB is supposed to maintain information of all authorised and approved changes. The CMDB should maintain a definitive state of the authorised or baseline configuration.

A better way is to use the auto-discovery tools to generate a report that shows the actual list of assets and their attributes deployed in the IT environment. This report can be compared against a similar report of authorised assets produced from the CMDB. Any discrepancies between the actual against the authorised (signalling a potential failure in the Release, Change and Configuration Management processes) can then be detected and appropriate corrective actions taken. This procedure can be automated if possible, so you get an exception report each day or each week.

Similarly, the above procedure can be used during the regular Audit or Verification activities in the Configuration Management process.

In any case, most auto-discovery tools cannot fully replace the manual and disciplined monitoring and control activities that need to be in place. The tools would not be able to produce good reports on the CI relationships which is an important area in Configuration Management. They are also limited in their scope and reach(i.e. those that can discover network configuration, may not be able to discover desktops configuration or applications and vice versa)

Nevertheless,  auto-discovery tools can help the Configuration Manager by reducing the effort involved in the CMDB set up, day-to-day monitoring, regular audits and verification. They should be used where feasible, and used correctly.