Saturday, March 28, 2009

More on the importance of CMDB

I was reviewing some other blogs this morning and came upon the announcement from Microsoft that Win server 2003 SP0 is no longer supported. Now I may have heard a chuckle there for a minute from some of you as to your thoughts of "who in the world would still be running Win2003 SP0?". Well let me share with you a story of an assessment I worked on prior to a virtualization project. The goal of the assessment was to prepare the organization for virtualization. The first step is to determine how many physical servers they have, measure their performance and through the wonderful world of capacity planning, determine how many ESX hosts they would need (loaded to a pre-determined level).

Well the assessment went off without a hitch and the results were presented to the project manager. He went through the roof at the results! The problem was not the report, but what the report told him. You see, they had just finished up a rather nasty project of upgrading all their servers from Win2000 to Win2003. The project was wrapped up and they had reported the completion of the project to the CIO. The assessment report showed the existence of 12 more Win2000 servers that had not been converted.

The point being, without a complete inventory of computing resources (CPU, memory, Network and storage) both physical and virtual, the fires just keeping being lit like the trick birthday candles. Put one fire out and it simply starts back up. You quickly run out of breath or remove the candle right? To turn your organization around from a tactical mode to a strategic mode, consider completing a through inventory of your organization.

Now, let's move on to how to conduct the inventory. There are usually three different means of conducting an computing resource inventory.
1. Have your agents (Tivoli, HP Openview, BMC Patrol and many others on the market) tell you what you have. The problem is you most likely do not have agents on every machine in your environment (think test/dev/qa) so this can not possibly be complete.
2. Send out the email to all business managers asking them to tell you what they have. Um, think about that. What would you report and how would you collect the information?
3. Utilize an agent less tool that can scan LanMan directories, perform an IP scan of your sub nets AND interview business units for possible hidden assets behind firewalls or on stand alone networks (you know they exist out there).

The inventory should then be validated with procurement and any provisioning/software distribution processes to ensure a complete listing. Only then can an organization start down the strategic road of knowing what they have and where they are going.

Keep in mind, an inventory can and most likely should include software, security patches and services installed or not.

2 comments:

  1. Sorry but what has this to do with CMDB? I love the anecdote, painfully real the 12 lurking servers. But this is basic IT Asset Management not CMDB. Relationships between CIs - which is the defining characteristic of CMDB - don't matter here. Instead of wasting fortunes trying to build CMDBs, folks should be doing the basic ITAM better first.

    ReplyDelete
  2. While I agree with you that the goal of a complete CMDB is to define the connections between assets and processes, it can also be used for the location of assets for proper change management. The usage of ITAM should provide "basic IT Asset Management", however it has been my experience that there are a lot of companies who do not know how many servers they have or where they are.

    Yes, the "defining characteristic of CMDB" are the relationships, it would behoove most companies to conduct a basic inventory assessment (not by email or agents) to help define their current assets so these issues don't occur.

    The problem of server sprawl or in today's sense, Virtual Server Sprawl can cause larger problems like software licensing issues, patch management and security.

    ReplyDelete