Hi and thanks for the post.  Sorry you are running into trouble.

1. Is this a range that was working on OME 1.1/1.1.1 but is not working in OME 1.2?

2. is the range something like 10.1.1.1-255 or similar?  Can you give me an example of the range?

3. Can you try breaking it up into several ranges for debugging purposes.  Either by protocol or some way to narrow it down to a possible problematic system?

I don't think at this point the issue would be the VMware memory leak, but I can't say for sure now.

We may need to collect discovery logs to see if we can find any device that might be giving us the trouble.  But we'll see.

Also, the Dell Troubleshooting tool is very helpful in these cases. But of course we need to get a better idea of a suspect IP address.

Thx

Rob

Hi Rob,

Thanks for the prompt reply. Just so you are aware, This was a fresh install of OME 1.2, not an upgrade over 1.1.1 :) I do have an OME 1.1.1 instance that resides on a different server.

1) Yep, existing ranges are  work in OME 1.1.1

2) Yep, this is a private range of 10.8.178.*

3) I have restricted the range to 12 IP addresses that belong to our ESX Cluster - I am pleased to say this is not causing the crash.

The issue appears to be isolated to a Windows 2008R2 server running as a VM. the SNMP configuration on the server looks fine. Dell troubleshooting tool shows things as fine as well.

It looks like my current workaround will be to exclude this machine IP from discovery and see how things go from there.

Is there any more detailed logs I can forward on for investigation?

Hi,

Thanks for trying to figure out where the problem is. Since you have said that it is because of a VM with Windows 2008R2 OS, so does this mean that a single discovery task on this server makes the service crash?

Can you provide the application logs which is there under "Logs" after the services crash?

Ok, so the suspect box is a guest OS VM?  Or it is ESX server hosting VMs?

If it is a regular Server with OMSA, the TS tool should return some sensible data along with the version of Server Administrator.  

Whichever test you run, you may compare the results of a good server to the suspect one.  That is often useful.

You should probably open a ticket as we will likely need to dig into logs to better identify the cause of the wayward server.

Rob

Hi Rob,

The suspect box is a Windows Server 2008R2 Virtual Machine running on an ESXi Host. The troubleshooting tool reports back cleanly for SNMP, WS-Man Protocols, and the information is the same between working and non working servers.

I'll get a ticket opened :)

Hi,

Thanks for the response.

Since it is application logs which is there in the UI itself, it would be great if you can attach a screenshot. If detailed logs are required, it would be better if you open a trouble ticket soon as Rob suggested already.