Spiceworks but otherwise .. I don't know, http://alternativeto.net/software/spiceworks/ On Wed, Apr 27, 2011 at 3:25 PM, Michiel Beijen wrote:

Would be great to have! Currently we don't have anything like this, you can however import inventory data from discovery tooling into the CMDB.

What's the best discovery tool (preferably open source) that people are using? Comments from the list are welcome! -- Mike

On Wed, Apr 27, 2011 at 5:42 PM, GARDAIS Ionel wrote:

...

Hi list,

We give a try to OCS Inventory to collect datas about the computers we manage. We ran into a few problems that led me to drop this tool …

Then I discovered OTRS for ticket requests : stable, efficient, all good. I installed the ITSM package on a test system and was wondering if a plateform plugin exists to automatically register a computer and update its features into ITSM ?

Thanks, Ionel --------------------------------------------------------------------- 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

Hello, We happen to be partners of both OTRS and OCS Inventory. 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. Regards, Leonardo Certuche www.itconsultores.com.co Medellín, Colombia On 27 April 2011 14:25, Michiel Beijen wrote:

Would be great to have! Currently we don't have anything like this, you can however import inventory data from discovery tooling into the CMDB.

What's the best discovery tool (preferably open source) that people are using? Comments from the list are welcome! -- Mike

On Wed, Apr 27, 2011 at 5:42 PM, GARDAIS Ionel wrote:

...

Hi list,

We give a try to OCS Inventory to collect datas about the computers we manage. We ran into a few problems that led me to drop this tool …

Then I discovered OTRS for ticket requests : stable, efficient, all good. I installed the ITSM package on a test system and was wondering if a plateform plugin exists to automatically register a computer and update its features into ITSM ?

Thanks, Ionel --------------------------------------------------------------------- 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

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

Hey all, honestly i do not see the point in pumping up OTRS with an asset management plugin as this topic is quite complex. If you take a look at a global market for ticket and asset tools, you will realize that if a tool combines both features it is either: - lacking basic functions of either AM or IM - to pumped up where nobody needs those features Personally I am only aware of one German and one American tool that combines both and I am neither totally satisfied with one nor the other. Sure ... would be quite handy for agents to directly check customers configuration while creating a ticket and such but where would you stop with AM functionality? Just basic hardware discovery? Additional OS, Software etc? Licensing? The scope of IM and AM is, imho, ways to huge for one tool to fully cover. Just my 2 cents. With kind regards, Studienkreis GmbH Mark Grzella Junior IT-Projektleiter Universitätsstraße 104, 44799 Bochum Tel.: 02 34/97 60 - 404 mgrzella@studienkreis.de www.studienkreis.de AG Bochum HRB 4581 Geschäftsführer: Franz Dahlmanns Bernd Kreissig (Sprecher) Bastian Schmidt-Faber -----Ursprüngliche Nachricht----- Von: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] Im Auftrag von Michiel Beijen Gesendet: Donnerstag, 28. April 2011 01:59 An: User questions and discussions about OTRS. Betreff: Re: [otrs] OTRS ITSM : computers discovery 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

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

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