Re: [otrs] OTRS ITSM : computers discovery

Dear all, Mike, of course as a Consultant I am very process focused, sometimes close to oversee the usability in terms of tool handling speeds =) =) =) Just kidding ... I really recommend to keep the insertion of new CIs a manual procedure. Of course, if you have a CVS file or such, and you have reviewed the content and verified against process related data (keep in mind that you can have multiple CMDBs) a mass-import of new CIs is ok. Also the mass-update, as long as you know the content of the mass-update. If you just want to insert “a few similar” CIs, lets say 6 new blades, I still recommend to insert them by hand, using the “Duplicate” action once the first CI has been created. And another dogma: no CI creation, deletion or modification w/o a Change request or a full Change! I like and give +1 for your idea to have the option of getting a kind of differences view BEFORE inserting or updating. Also the option to decide if a mass-insert/update should only update existing CI or also create new CIs if no dataset matches an existing CI. The integration of third party tools is a milestone that is just in front of our door, looking at the Generic Interface implementation in OTRS 3.1.x! I would love to see OTRS customers to share their function requirement specifications about connectors to Microsoft® ActiveDirectory®, LANDesk®, other OTRS CMDBs, SAP® Asset Management platforms, etc ... Mike, that is what I think =) Cheers, Nils On 28.04.2011, at 01:58, Michiel Beijen wrote:

Yeah; this is a valid point: you really should control the changes done to your CMDB.

That said, auto-populating and/or updating the CMDB with a discovery tool should not lead to an out-of-control configuration management process per se.

The problem is that you would NOT want to populate and/or maintain your CMDB manually once you have a significant amount of CI's. (Did you ever deploy 50+ new servers and manually enter the data in the CMDB? That is *not* a good Config Management practice, that's asking for input errors!)

Also, please bear in mind that it's great if you have a manually maintained CMDB but it's CRUCIAL to verify this against the actual truth so you can check if you're still in sync. Of course discovery tooling can only supply a *part* of this truth, using discovery data you usually can not tell: * whether or not a machine has a support contract * the purchase date, PO number, vendor information, cost center * the physical location (room x, rack y) * the kind of service it's running, and if it's a test or production environment etc; this data needs to be manually added to the CMDB.

One great option would be if you would get 'diffs' of your CMDB using discovery tooling or such and having the ability to link this to changes; for instance, if a server suddenly reports a different IP address, or if your discovery tool finds a new router on the network, you should be able to get a 'diff report' for this and link it to the change request that made this happen.

In my opinion the process of updating a selected amount of fields from discovery tooling is completely valid and good practice, as long as you have and monitor these 'diff reports' and make sure you link these to the change requests or other sources that made it happen; this is also a very nice way to make sure no unauthorized changes are performed.

@Nils: what do you think?

-- Mike

On Wed, Apr 27, 2011 at 10:38 PM, Nils Leideck wrote:

...

Dear all, On 27.04.2011, at 21:50, Leonardo Certuche wrote:

Please keep in mind that auto-populating your CMDB using a discovery tool will lead to an out of control configuration management process.

What we do is the following: we get the inventory from OCS, export it to CSV, and then import it to OTRS using the ImportExport feature. That way you'll have an starting point for your CMDB and any change you perform after that should be done by hand either through the change process or the configuration process. I know it sounds too manual but that way you'll keep control on the changes performed to your configuration items.

I can’t give enough acknowledges to what Leonardo said !!! Configuration Management and Inventory is a different and should stay a different !!! Cheers, Nils -- Nils Leideck http://webint.cryptonode.de / a Fractal project

-- Nils Leideck http://webint.cryptonode.de / a Fractal project