This is kind of wild but I guess not really if the "netmon" code was just reused. It's a new product but it looks like it is doing the exact same thing as IT Assistant used to whenever I tried to setup a discovery and inventory. Since this is a new product and looks like there is some actual developers behind it now can someone help me figure out what is going on?
In the past, there were recommendations to divide and conquer a discovery range. The problem is that servers come and go and being an OpenManage Essentials admin is not my full-time job. Perhaps some intelligence in the code that skips a box if something is causing it to peg?
Here's an old thread on the IT Assistant forums discussing this. http://en.community.dell.com/support-forums/servers/f/177/t/19287828.aspx
Hi and thanks for the post.
A few quick questions...
1. What protocols are defined in your discovery wizard?
2. How much memory on your OME server?
3. How many cores on your OME server?
4. How did you define your ip/hosts in the disc wizard? (e.g., 10.1.1.1-255, single ip addrs, etc.)
DELL-Rob CSocial Media Support#IWork4Dell
1. ICMP, SNMP, and WMI
2. 4gb RAM
3. Single core
4. IP Range (10-254)
Server is a ESX guest. I can up the RAM and cores if need be.
Thanks for the quick reply. Yeah, I think the readme asks for 4 cores. Can you bump it up and give it another shot?
I increased it to 8gb RAM and 4 processors. Right now it seems to be going through and finishing discoveries with inventory properly. I have some other issues but will post in seperate threads so as to keep this one on track incase the issue comes back.
Ok, good deal. Thanks for the update. I'll keep a look out for your new posts :)
I just checked my Processes with procexplorer. There must be 16 pages of calc.exe running under the DSM_OMSE_Netmon_32.exe process. Memory for each is about 4628K. Memory is almost eaten up. Essentials is running rather slow. What is up with that?
Strange. The only way I could get calc.exe to show up in procexplorer was to start up the Microsoft calculator program. Does your calc.exe entry show a path of \windows\system32\calc.exe ?
Actually, it's C:\windows\syswow64\calc.exe.
But, I don't think that's the issue. The issue is....what is kicking this thing off? Is the possible answer buried in the top ITA thread where it gets kicked off in an inventory or a discovery? I'm still digging today, but had other priorities from last week to deal with.
Is this a fresh OME install or upgraded from ITA? thx.
If you have a default install and db admin privileges (and you are a bit SQL savvy), you could try something like this:
sqlcmd -E -Q "select ExecutableName from OMEssentials.dbo.EventStoredAction"
That will confirm that we don't have any event actions defined.
Just now....Everything was quiet on the OME server; no calc.exe's in the process list. I rebooted a box with a known good SNMP install/config, from a CMD windoe had ping -t going to the box. As soon as the box started pinging, the calc.exe's starting coming in (39 to be exact) and indented under the DSM_OMSE_Netmon_32.exe process from within ProcessExplorer. I checked the Discovery/Inventory portal; nothing going on.
Bizarre! Hmmm...ok and any results from the sql command in my previous post?
From the prior posting, I killed the entire Netmon process to get rid of the calc listings and then restarted the DSM Essentials Network Monitor process. Prior to this, I had tried running a Refresh Inventory and a Refresh Status on a known bad SNMP config to see if there was something hanging. That did not produce any calc processes.
I stopped/restarted the DSM SA Data Manager on that box that I rebooted to see if it has the same effect of creating calc's on the OME server, but it didn't.
Just ran it. A lot of sendmail.exe listings, and one Calc.exe listing with a system32 path.