We have the same problem, the sensor shows 'Failed', but on the SMH everything is fine. So it`s not a problem on the HP Server.

Update: some old entries in the IML were the reason

Please use the SNMP Tester and run a "Custom OID" test with this oid:

1.3.6.1.4.1.232.6.2.11.2.0

If it returns a 4, the Integrated Management Log is causing the failure state. If it returns a 2 the IML is working correctly.

If the IML is working correctly, please run this "Custom OID":

1.3.6.1.4.1.232.6.2.7.1.0

If it returns a 4, the POST error recording feature is causing the failure state. If it returns a 2 the POST error recording feature is working correctly.

Hmm. Our "Critical Errors" according to HP SMH are that some of the spare network sockets are not in use...!

All our ILO's are down since this update! Disabling the complete health sensor by setting it to 'warning' is no solution because it is only the Overall state that is "failed", we cannot miss warning on fans and temperatures. Please have a fix for this. Spare sockets not in use??

Would it be possible to provide us with the exact error message you are getting possibly with a screenshot?

This sucks. 29 of our SNMP ProLiant Health Sensors in error state since updating to 14.4.x. Check in Integrated Management Log: Overall System Status is OK.

Herman

If you use the SNMP tester as Johannes mentions above does it return a 4?

For the record.... this update broke all of my Proliant sensors as well. I've not had a chance to investigate further - I had to pause them for now. Gotta say, this was a first for me. My PRTG updates are always rock solid.

I am still getting the error after clearing the IML log

I cleared the Integrated Management Log as mentioned above to resolve this.

I faced the same issue, but I found that I can clear old logs by using the following command -

"C:\Program Files\Compaq\Cpqimlv\cpqimlv.exe" /clear

Paessler need to have SNMP trap for logs on older servers.

Thanks for the help in the right direction.

Cheers

I had to clear IML Log in ILO to get the SNMP HP System Health Sensor green again.

BUT because not all network ports are used, It always creates an inl entry that the port is down. Can anybody tell me how to avoid that? We have the same problem with hp insight manager, sends emails all the time. Thats why we wanted to get rid of it and use PRTG.

Admin hot happy

cheers

the commando "C:\Program Files\Compaq\Cpqimlv\cpqimlv.exe" /clear worked perfectly!

I am having the same issue as described above. I ran the command to clear the IML. That worked, but did not clear my issue. I did the SNMP test with the first OID and got a response of 4. So I did the SNMP test on the 2nd OID and got a response of 1. Since this does not match the 2 responses that you listed and it is still not working I believe there is the issue. I looked at the SMH on the HP server and all is Green.

The server in question was rebooted on 11/22. The PRTG server was rebooted last week. None of the channels in the sensor show anything.

Is there any other channel in a error state? The CPU fan for example? You could try to restart the entire server which might help to get rid of those errors :)

All of the channels in this sensor have no information. All other sensors on this server are Green. The server was rebooted on 11/22/2014 for Windows updates. At that time the latest version of HP System Management was also installed. This is a production server so rebooting it right no is not an option. I have rebooted the PRTG server and that did not resolve anything either. I currently have 3 servers that are reporting like this one. All of my other HP servers are reporting correctly in PRTG.

Please try to restart the SNMP agents: /etc/init.d/hp-snmp-agents restart

Does this bring remedy? :)

From our side the same problem, we have around 50 of these sensors, all of them did go into error after installing update 14.4.12.3510+ (overal status failed)

For the sensors which were monitoring linux systems it was sufficient to clear the iml log via the ilo console, this cleared the down status for these sensors.

For the sensors which are installed on windows systems, clearing the IML logs doesn't seem to solve the issue, neither does restarting the HP Systems Management Agents. On all affected sensors installed on windows systems the CPU Fan has a status of "other", I don't know however if this is causing the "down status" of the sensor.

Paessler mentioned that they have reworked the sensor to update the behaviour with the latest HP update, so we have done a test case, installing the latest proliant support pack on an HP Proliant ML 110, the installed version of the HP systems management agents is 10.0.0.0
Installing the updated proliant support pack, including the updated HP Systems management Agents did not resolve the issue. We performed a second test by removing the sensor on the server and re-adding it, and then the situation gets even worse. Before removal we had the following channels with status:

CPU Fan Status	3	Other	Other	Other	
Disk Controller Status	41	OK	OK	OK	
Downtime	-4		 	 	
Fans Broken	5	0 #	0 #	0 #	
Fans Running	4	0 #	0 #	0 #	
Fault Tolerant Fans Broken	7	0 #	0 #	0 #	
Fault Tolerant Fans Running	6	6 #	6 #	6 #	
Overall Status	0	Failed	OK	Failed	
Power Consumption 1	33	55 W	50 W	90 W	
Power Consumption 1 (%)	34	12 %	11 %	20 %	
Power Consumption 2	37	65 W	60 W	100 W	
Power Consumption 2 (%)	38	14 %	13 %	22 %	
Power Supply 1 Condition	36	OK	OK	OK	
Power Supply 1 Status	35	No Error	No Error	No Error	
Power Supply 2 Condition	40	OK	OK	Failed	
Power Supply 2 Status	39	No Error	No Error	General Failure	
System Fan Status	2	OK	OK	OK	
Temperature 01(ambient)	8	24 °C	18 °C	27 °C	
Temperature 02(cpu)	9	40 °C	40 °C	40 °C	
Temperature 03(cpu)	10	40 °C	40 °C	40 °C	
Temperature 04(memory)	11	27 °C	23 °C	36 °C	
Temperature 05(memory)	12	27 °C	22 °C	36 °C	
Temperature 06(memory)	13	31 °C	26 °C	38 °C	
Temperature 07(memory)	14	32 °C	27 °C	40 °C	
Temperature 08(powerSupply)	15	43 °C	39 °C	45 °C	
Temperature 09(powerSupply)	16	35 °C	31 °C	37 °C	
Temperature 10(system)	17	43 °C	38 °C	46 °C	
Temperature 11(system)	18	32 °C	28 °C	36 °C	
Temperature 12(system)	19	39 °C	35 °C	44 °C	
Temperature 13(ioBoard)	20	32 °C	27 °C	35 °C	
Temperature 14(ioBoard)	21	33 °C	29 °C	36 °C	
Temperature 15(ioBoard)	22	32 °C	28 °C	35 °C	
Temperature 19(system)	23	22 °C	18 °C	26 °C	
Temperature 20(system)	24	28 °C	24 °C	31 °C	
Temperature 21(system)	25	28 °C	24 °C	31 °C	
Temperature 22(system)	26	29 °C	24 °C	31 °C	
Temperature 23(system)	27	38 °C	33 °C	40 °C	
Temperature 24(system)	28	33 °C	28 °C	35 °C	
Temperature 25(system)	29	32 °C	28 °C	34 °C	
Temperature 26(system)	30	32 °C	28 °C	34 °C	
Temperature 29(storage)	31	35 °C	35 °C	35 °C	
Temperature 30(system)	32	67 °C	59 °C	70 °C	
Thermal Status

After the removal and re-addition of the sensor, only the following channels appeared again, all without status:

CPU Fan Status	3	Other	Other	Other	
Disk Controller Status	8	OK	OK	OK	
Downtime	-4		 	 	
Fans Broken	5	0 #	0 #	0 #	
Fans Running	4	0 #	0 #	0 #	
Fault Tolerant Fans Broken	7	0 #	0 #	0 #	
Fault Tolerant Fans Running	6	0 #	0 #	0 #	
Overall Status	0	Failed	Failed	Failed	
System Fan Status	2	OK	OK	OK	
Thermal Status

We hope that paessler can repair this sensor, as in our environment this was one of the key sensors to justify the investment on this product.

Hi Ronny,

Sorry to hear that the update broke your windows server monitoring. The CPU state being "other" is indeed causing the sensor to error. This could be caused by a cold reset or any other unexpected shutdown. Could you try it with one server to completely reboot it and see if that fixes the error?

There's actually nothing on our end that we could do about it - we needed to switch to that OID since the old one we've used became obsolete with the latest HP version. So it's either having no monitoring or more detailed monitoring - of course, we went for more details, but since our testing systems were in a state where the IML was empty and no other errors, we didn't think this would cause such trouble.

I found another solution to the IML issue. Run the IML interface, select all entries and mark them repaired.

According to this site there's a way to do it from the command line, but it's not a one-liner. http://h30499.www3.hp.com/t5/ITRC-HP-Systems-Insight-Manager/Clearing-IML-entries/td-p/3252551#.VI3MjTctB34

-- Ken

Hello.

I had the same problem.

• Run "C: \ Program Files \ Compaq \ Cpqimlv \ cpqimlv.exe"
• Keep a backup of the log. Menu "Log ---> Save Log as ..."
• Once saved, should be emptied. Menu "Log -> Clear All Entries ..."

Once these tasks, it has worked sensor.

Greetings

Clearing the IML worked for me. Thanks!

Hello,

I am experiencing a similar issue to the above. I have installed redundant power supplies in 2 of my HP ProLiant servers this past weekend, and since then my PRTG installation is telling me that PSU1 on each of the servers is in a degraded state.

I check the iLo System health page on both of the servers and it tells me that the power supplies are perfectly ok and fully redundant. I have cleared the IML logs on both the servers but this has not resolved the issue.

I then ran your SNMP Tester utility (v5.1.3) using the custom OID's above. The first gives a result of 2, so the IML appears to be working correctly. The second custom OID gives me a result of 1. What does this indicate please?

Hi Paragon,

Sometimes restarting the target server redeems issues like this - can you try that? :)

Regards

The 2 servers are both live production servers, so not easily restartable. I will attempt to find some downtime to do so. In the meantime, can you tell me what the response of 1 to the second custom OID means please?

Many thanks,

Hehe okay, not so easy then. The integers represent the following states:

1. Other
2. Ok
3. Degraded
4. Failed

The problem with this thread is that YES, clearing the IML will make the sensor go back into a good status. However, every time the server is rebooted(and all of the NICs are not plugged, for example) "errors" show up in the IML and the status goes back to Down. Why is it not possible to simply disable an individual channel? This would solve our problems as we see value in the rest of what the sensor does, but not this IML noise we can safely ignore.

Has there been any progress anyone can report on this? It's such a massive annoyance that all one can do is clear the log manually.

Hiya,

You can simply click on this particular channel and set the lookup to None. This will prevent the senor from switching its status.

Best regards, Felix

Hi Agent_Mulder

I had the same problem, but updating the ILO and System management (approx the whole Proliant) did the trick. I also had a second Raid Controller in one server, where no HD were attached. I had to disable it to get all green in PRTG.

From my side I would say that the behavior of PRTG is correct, showing errors when IML is having errors. I mean you want to KNOW if your server has errors.

regards Thomas

After changing the lookup behaviour (e.g. from Error to None) to suppress this channel, additionally you will need to Reload the definition as described in the linked resource. Afterwards, a new check will need to be performed before the new value is reflected in the sensor status.

• You can (re)load the defined lookups in the custom folder by clicking the Load Lookups button in the PRTG web interface under Setup | System Administration | Administrative Tools.

• A sensor whose lookup file you have modified and reloaded will not re-evaluate this lookup before the next sensor scan. For sensors with large scanning intervals, use the Scan Now option from the context menu to immediately apply the new lookup definition and to avoid an incorrect sensor status.

Hi,

Six years later this issue is still really annoying, it took us days to figure out that this was an error logged into IML logs which put this sensor's Overall Status down...

@passler : Can you please update this sensor's documentation with this known issue ? It could save a lot of time for futur HP's servers admins. ;)

Regards,

Clément

Hello Clément,

I will propose this to our team. Since it isn't issue in PRTG, it could be possible that we won't add it into our documentation.

Kind regards

Felix Wiesneth - Team Tech Support