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 <nils.leid...@leidex.net> > 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 --------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
