Certain Servers not showing up or showing as "Unknown"

Hi Terry and thanks for the post.

The first thing I would do is check the FAQ on delltechcenter.com/ome under section 3.6.

Another frequent problem is sometimes people forget the snmp comm string is case sensitive.

Lastly, run the Dell Troubleshooting Tool installed on the OME desktop.  The results of the SNMP test *must* include the Server Administrator version.  If you don't see this, that's  an indicator OMSA is not configured correctly.

Firewalls often cause mischief as well.

Thanks,

Rob

What about domain authentication?  When I created the discovery ranges I used a generic account we commonly use to run services because it’s password never expires ,etc….   I just realized that the servers I’m having an issue with are not in the domain.   Do I have to create a discovery that uses the local server credentials or can I use a different method of discovery for a subnet of servers that doesn’t use domain credentials?

You will need valid credentials for those servers. Local accounts are fine if the same credentials work for all those servers which are out of domain. If not you'll need to create different ranges with diff credentials.

Hope that helps.

Rob

Ok, if you can tell me what the result set from the TT SNMP test gives you (be sure to mask any private data).

thx!

Just another couple of things to add:

1) What types of servers are they - Are they supported?

2) Are you discovering the servers of the Idracs? For anything with Idrac 7 onwards, use the wiard and discover those servers with idrac option. For anything else I use SNMP

3) If they're windows boxes, make sure SNMP is set to accept connection from your OME server.

As Rob has already pointed out - the troubleshooting tool can save much head scratching!

All of these servers are Dell blade server M600 or M610.  They are supposed to be supported even if the warranty has expired and by that I mean just phone support if necessary.

I think most of these servers have Idrac6 or below.  Yes I'm installing the SNMP service on each windows server and under the "Security" tab I have the Accepted community names entered and I also enabled "Accept SNMP packets from any host".

The server I'm testing with shows up under devices, servers and I can see all the information about it but it won't show up under "non-complient" or "noninventoried"

Hello,

We are having this issue on several servers. They are all Windows servers and a mix of 2003 versions. OSMA is installed and configured. Some are 7.x most are 8.10. OM Essentials version is 2.0.0.1926. There are multiple sites involved and they all have some that work and others that do not. SNMP settings for discovery have been triple checked and I have been through the suggested troubleshooting steps as listed above (and in other threads), to no avail.

When using the troubleshooter, we get the below error.

Error The SNMP read request has failed for Get Community name - XXXXXXXXXXXX

I have checked the SNMP settings and a netstat reveals that the server is listening on UDP port 161.We have tried cycling the services, rebooting the servers and re-installing the OMSA's, still no love. The servers continue to show up as unknown and we get the same troubleshooter error message. Keep in mind that other servers of the same like are working from behind the same infrastructure.

We are at our wits end and left scratching our heads. Please help!

Jatman1, when you rebooted the servers were they set to take a system inventory (CSIOR)? If not, then I would suggest having them do so, then re-discover them in OME. I had a bunch of servers show up as "Unknown" and was able to get them into OME properly by having them do a CSIOR and re-discovery.

But if SNMP isn't working then OME's not going to pull the data whether it's recent or not, so...

Have you checked that there are no firewalls/routing problems that are preventing your OME server from getting an SNMP read request? Can you get a proper read request using the troubleshooter from any of your servers? If you can, then the problem's not on OME's end.