HP iLO messing with Lansweeper

[nmulvihill]

In my network I have a few dozen servers who all have iLO enabled. When I scan the ranges with the iLO. Some of the iLO's are scanning as Linux devices, some as Web Servers, Some as Remote Access Controllers, network switches, etc. 90% of them come back with an ssh credential error (Even though I know it works). If I scan the IP related to the iLO, the server gets assigned the same IP and then it will get set back to the correct IP when I scan the range in which it actually resides.

The AssetName's for the assets is very, very inconsistent. Some of the assets discover more when SSH does work. I have a few that will work when scanned and then fail 12 hours later. I know Lansweeper does not support SSH on iLO's. I am in contact with support but I would like to see if any other LS users have run into similar issues or have an idea how to fix it?

I would be entirely okay with dynamically ignoring all iLO's on the network, but I am not sure how to do that. I cannot ignore IP ranges as there are other devices on the same subnets and I need it to be dynamic.

[fjca]

Haven't tested that with iLO's yet, but I've had some similar issues with some Appliances, firewalled machines, KVM's, etc. I think Lansweeper "classifies" machines depending on which services answer first, so we get those issues.

What I've done is just edit the Asset, and fix the "Asset Type" to whatever best fits the machine, just check the padlock checkbox next to Asset Type.

If your iLO devices use fixed IP Addressing, you can also do a IP Range entry just for them, and them disable SSH and Windows detection (those are the only ones that can disabled, AFAIK). Of course, if they are on DHCP or are transient in nature, that won't work very well...

I'm a bit surprised SSH works (never tried on ours), since it requires dmidecode, sudo, etc, but iLO's also support SNMP, so maybe you can set an SNMP credentials on that range, our multi-protocol devices (printers, etc) seem to respond better to SNMP than HTTP/HTTPS...