0 Replies Latest reply on Mar 2, 2009 10:55 AM by rick.kraemer

    Using vPro to Create and Audit ITIL Configuration Management Databases (CMDB)

    rick.kraemer

      Hello, I’m Rick Kraemer, one of the enterprise architects here at Intel. I’ve thought through a number of initial topics to start discussions on the integration of vPro technology and the IT Infrastructure Library (ITIL), but I keep coming back to Change Management, and the Configuration Management Database (CMDB). Since the CMDB is so central to every data-related ITIL function, it seems like a great place to start.

       

       

       

       

      After you’ve done all the tedious work to design a CMDB, your most time consuming tasks will be 1) populating all of the initial Configuration Item (CI) data, 2) maintaining the CI data, and 3) validating the accuracy of CI data through audits.

       

       

       

       

      Veterans of CMDB implementations tell us to start slowly, learning all of our lessons on small sets of data, and gradually working up to the full data set. This presents somewhat of a catch-22, because a CMDB would be a great resource to identify a small data set. But you haven’t populated your CMDB, so you can’t query it for insight. This leaves you with a couple of possibilities. You could choose a new CI that you’re introducing into your environment, and add each CI as you deploy it, growing the CMDB one at a time. Or you could pick out a small set of deployed CIs to inventory and load into the CMDB.

       

       

       

       

      Using AMT to load new CIs into the CMDB. First, you’ll create CIs in the CMDB for your new Intel Core2 or Centrino 2 processors with vPro technology, and set up relationships between those CIs (which OS runs on this hardware, the software versions running on the OS, etc). Then, using AMT Remote Configuration and third party software, you’ll automatically provision clients using either delayed or bare metal configuration. Once the configuration is completed, the third party software sends an update to your change management database, updates the service request ticket in the service desk, and relates the new CI to existing CIs in your CMDB.

      Loading New CIs into the CMDB.jpg

       

       

       

       

      Using AMT to load existing CIs into the CMDB. Alternatively, you can select a subset of Intel Core2 or Centrino 2 processors with vPro technology, which you’ve already deployed into your environment, and auto-populate their CIs. Using vPro technology and third party software, you would query your systems, either reading CI data placed in the third party data store (3PDS) by a third party client application, or by using Out Of Band (OOB) access to turn on and query the remote client. Instead of sending staff to find, power up, and inventory systems, you would complete the work from a central console. The third party software would detect and inventory the client PC, then submit standard change requests into your change management system, which would then enter them into the CMDB. Intel case studies have shown a whopping 99.6% improvement in PC discovery time, and a 22.2% improvement in inventory success, so vPro technology should provide significant efficiency to initial CMDB population.

       

       

       

       

      Using AMT to maintain CIs in the CMDB. This is a broad topic, involving release management and change management, among others, so let’s talk about this feature in another post later on.

       

       

       

       

      Using AMT to audit the CMDB. CMDB audits have the potential to consume vast resources, and be fraught with delays. Asset discovery tools will speed up the process, but you’ll always have clients that are powered down, or off-site, and can’t be inventoried without hours spent chasing down the hardware. Intel case studies show that typical inventory accuracies run about 84%, but studies implementing vPro technologies show inventory accuracies at 98%. By using vPro technology and third party software, you can audit your platformsfrequently, either reading CI data placed in the third party data store (3PDS) by your third party client application, or by using Out Of Band (OOB) access to turn on and query the remote client. These audits allow you to identify CMDB discrepancies, and launch either standard change requests in Change Management, or service request tickets in Incident Management, depending on how much human validation you’d like. So when the next browser virus strikes, you won’t have to rely on last year’s CMDB audit to determine who has downloaded newer versions of the browser; it will be fresh and available in your CMDB.

       

       

       

       

       

       

       

       

      Auditing the CMDB.jpg

      I’m eager to hear from you regarding the ITIL CMDB, and how vPro integration makes CMDB maintenance more efficient, so I’ll be looking forward to your comments. I’ll be working on my next installment soon, so also let me know if there is particular topic you’d like addressed.