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