My customer want to find Hardware Logs and inventory data in the OS (Windows or Linux).
And I could find that the System Center Operation Manager (SCOM) can do some of the job.
But my customer also want to find that the OS agents which could collect them.
So my question is, is their any kind of agent program that can support to collect them?
and Is their any method to collect them using IPMI 2.0?
and the last, Does the OSs can collect the event logs from the CIMC ? If it is, how can I get it?
It would be really helpful to our customer when you let me know about above issues.
As you noted, Microsoft's System Center Operations Manager (SCOM) has the ability to collect hardware and software information. This is a very mature management platform that Microsoft has been selling for more than 20 years and it widely adopted by nearly all hardware and software vendors that support Windows hardware and software. As a result, most vendors have what are known as Management Packs for SCOM that will collect the information unique to the vendors' hardware/software and report it to SCOM. Cisco also provides management packs for both UCS managed and standalone servers. See https://communities.cisco.com/docs/DOC-37153 for download information on our management packs.
Microsoft is not the only vendor for such capabilities. HP has OpenView. IBM has Tivoli. Computer Associates has their software, and there are several others. SCOM happens to be the management package with the largest market share and Cisco has a great working relationship with them on SCOM.
Thank you for your comment and we could do the job with SCOM and management pack that you mentioned above.
and one more thing that I want to know is, does Cisco UCS C-series could support BMC detection through ACPI?
Since we also want to collect the data through the Microsoft server's event viewer subscription like below in windows server 2012 r2
"could it be possible to view the SCOM data in windows event viewer menu?"
Not by default. This is sort of a backwards request. One of the purposes of SCOM is to make it so the operations manager does not have to plow through the event log to find issues - SCOM surfaces the issues that may be written to the event log. Additionally, not all things are necessarily written to the event log. That said, SCOM has the ability to execute a command line/executable/script/etc. as an action for any alert. If you really want the information to be stored in the event log in addition to being stored in SCOM's database, you could write a script to write the information into the event log so you had the information in two places. The bottom line is that it can be done. But the obvious question is why would one want to do that?
"Is there any kind of method for collecting system events using IPMI 2.0?"
That can be accomplished via a Management Pack. SCOM itself does not perform anything via IPMI natively, but there is nothing to prevent someone from creating one. Though it is not IPMI, there is a template for SMASH (http://blogs.technet.com/b/momteam/archive/2012/04/02/ws-management-smash-device-discovery-template-released.aspx). I know that SMASH is not IPMI, but SMASH builds upon IPMI. So if someone really wanted an IPMI template, it could be written. If there is demand for it in the market, it may have already been written. There is a large community of vendors who write management packs (http://systemcenter.pinpoint.microsoft.com/en-US/home).
The architecture of SCOM is that there is a centralized server (farm) that collects the information from agents running across the environment. The agents are very lightweight. By that, I mean that they simply provide the information requested that is defined by management packs installed on the central server (farm). So most of the time, the server is communicating with an agent that resides on a target machine. IPMI is a bit different in that it allows for collecting information from a physical device that may not have an operating system running. This means there is no agent. SCOM can accommodate this by running a process on the central server (farm) that polls those physical devices. This puts a larger load on the central server than the agent model, so you would need to take that into account when sizing the system. And, that polling routine would need to be written to use the protocol desired and to collect the specific information to be collected. SCOM already has some existing management packs that accomplish this for monitoring switches and routers in a generic fashion (though not using IPMI). So it can be done. I simply don't know if anyone has written such a management pack.