ITIL configuration management in virtual environments

>a. user permissions.

Can you elaborate on user permissions in virtual environments?

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?

ITIL is a framework, which is about good procedures and documentation.

Configuration Management, is about the documentation of changes, against the Configuration Database.

So re user permissions and security, are you saying you just need to document what those user permissions and security settings are? And thats it?

you need to ensure, that permissions do not change, or affect the service.

Do ITIL do any books on exactly what they expect from good configuration management?

Im struggling to see the real benefits of configuration management to be honest.

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

>>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

when you build a system you should document it and maintain it

i,e, SAN (Storage Array Network) capacity, connected hosts, allocated storage etc

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...

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