ITIL configuration management in virtual environments
1) If you were to do an audit of "configuration management" (as defined by ITIL) in an environment with all virtual servers, and desktops, what sort of areas would you look at for good controls? Can you give perhaps 5 top checks in this area?
2) What kind of things can go and do wrong with poor/lack of configuration management? Whats the risks?
Can you elaborate on user permissions in virtual environments?
Pau Lo
ASKER
What exactly is ITIL asking you to do with good "configuration management"? I.e. what would poor configuration management look like? What does good configuration management look like?
Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
ITIL is a framework, which is about good procedures and documentation.
Configuration Management, is about the documentation of changes, against the Configuration Database.
all my experience with ITIL is they give you a process thats generic enough you should be able to apply it to anything but with no real guidance for specific products
its just a case of common sense, if you have good change management then config management is just checks on that to make sure it matches documentation
Pau Lo
ASKER
>>its just a case of common sense, if you have good change management then config management is just checks on that to make sure it matches documentation
Could you just elaborate a bit more on this please
Chris
when you build a system you should document it and maintain it
a change request would document any changes to this configuration and then the document would be updated this would give you your configuration management.
Obviously you can apply config management to lots of things and not just hardware or software it could be licensing agreements
So lack of configuration management is essentially
Build server X - document settings
Change setting to server X - dont (or forget to) document the updated (changed) setting
And thats all there is to it? Most systems I would imagine can report on current settings anyway, without a need to duplicate that with your own document - so I am struggling to see the whole point in it, or what can go wrong...
Chris
a lot of it depends on the size of the system and the amount of IT staff working on it i ripped/paraphrased this of the wiki page which i think sums up why it might be important for you and the point i was trying to put across
Technical - Data that describes the CI's capabilities which include software version and model numbers, hardware and manufacturer specifications and other technical details like networking speeds and data storage size. Keyboards, mice and cables are considered consumables. this helps with support and capacity planning, helps to resolve issues and by knowing what the system is designed to do and capable of aids planning for the future
Ownership - Part of financial asset management, ownership attributes record purchase date, warranty, location and responsible person for the CI. Identification numbers like bar codes and type, like software, hardware and documentation are also ownership attributes.
Helps track items for support and ensures things are maintained and refreshed
Relationship - The relationships between hardware items (e.g. a printer), software (e.g. drivers), and users (i.e. Alice). Helps to assess impact of an item on the environment i.e. server X goes down, its has application Y installed on it which affects users A, B and C
Can you elaborate on user permissions in virtual environments?