Only two things to configure to scan for SNMP.

1) When you run the Scan LAN make sure you check off the SNMP check box.
2) Make sure that your PUBLIC variable is set the same on both Scan LAN and your SNMP device. Ususally it's set to PUBLIC.

Legacy Forum Name: Monitor Sets,
Legacy Posted By Username: doug.jenkins@ispire.ca

'public' should be in all lower case as this variable is case sensitive.

Legacy Forum Name: Monitor Sets,
Legacy Posted By Username: ETG

Are people using the SNMP function regularly? Is it working well?

Did they ever fix the "SNMPGET.EXE" problem that existed in the past where a ton of that EXE process would run on servers constantly and drag down performance?

Legacy Forum Name: Monitor Sets,
Legacy Posted By Username: kentschu

kentschu

Are people using the SNMP function regularly? Is it working well?

Did they ever fix the "SNMPGET.EXE" problem that existed in the past where a ton of that EXE process would run on servers constantly and drag down performance?

We submitted a case and the developers pushed down to us a new version of the executable, apparently taken from K6, that is much more efficient. Apparently the old version would check its entire library of MIBs when the executable, and the new version was programmed to only check the MIBs assigned to the device. Much more efficient, and we did see a decrease in processor utilization. The behavior went from drastic spikes maxing the CPU to a steady flow of rolling waves while watching the graph in task manager. It was still recommended by them that the SNMP monitoring be assigned to a non-critical workstation or fileserver device that could dedicate its processing power to scanning the network. I think this should also be done with LAN Watch, which has crippled several of our domain controllers (making the AD integration useless, but it wasn't very useful in my eyes anyway.)


That said, I work for a different firm also using kaseya, and we have yet to implement any SNMP monitoring. I'm beginning to toy with the trap scripts that were posted, but I think we will be holding out for K6 before making any big moves to SNMP given what a pain it was in my past experience.

Legacy Forum Name: Monitor Sets,
Legacy Posted By Username: drodden

What version of snmpget did you receive from support? I have a temporary workstation that I like to run some scripts on and noted it is still getting the flood of snmpget executables every few seconds. We also just upgraded to the new k6 release but maybe that particular file did not get updated?

Legacy Forum Name: Monitor Sets,
Legacy Posted By Username: neteffect

Unfortunately I don't have access to it at this point and couldn't give you any info, but it didn't stop the flood of SNMPGET commands, just lessened the load they placed on the processor. There is a SQL query you can use to limit the number of concurrent threads that are opened. Unfortunately, I don't have that either at this time but I may be able to dig it up for you. I believe it exists on the forums somewhere, but may also be available via standard support. I believe it can also be adjusted in the KaseyaD.ini file for an agent. The line 'SNMPConcurrentThreads' has a default value of thirty, and Kaseya recommends changing this to 5. The SQL query allows you to change this from the backbone, but you could easily write a script in Kaseya to query the contents of that file and change any values of 30 to 5. Unfortunately, with the original SNMPGet process, 5 threads still caused the CPU to peg.

Legacy Forum Name: Monitor Sets,
Legacy Posted By Username: drodden

drodden

Unfortunately I don't have access to it at this point and couldn't give you any info, but it didn't stop the flood of SNMPGET commands, just lessened the load they placed on the processor. There is a SQL query you can use to limit the number of concurrent threads that are opened. Unfortunately, I don't have that either at this time but I may be able to dig it up for you. I believe it exists on the forums somewhere, but may also be available via standard support. I believe it can also be adjusted in the KaseyaD.ini file for an agent. The line 'SNMPConcurrentThreads' has a default value of thirty, and Kaseya recommends changing this to 5. The SQL query allows you to change this from the backbone, but you could easily write a script in Kaseya to query the contents of that file and change any values of 30 to 5. Unfortunately, with the original SNMPGet process, 5 threads still caused the CPU to peg.

Hi all,

Having so many problems with SNMP scanning.

I am NOT able to discover a single SNMP device in my Network.

3rd party tool solar winds tool succesfully discovered our Cisco Switch device.

Sadly, when I run SNMP LAN watch, it doesnot discover anything.

It discovers the IP where the N/w device is setup. But it is discovered as 1 more system in the N/W but NOT as a SNMP device.

Made sure that community is same (confirmed with N/W admins)

Also ran the query which will limit the CPU usage on the machine I am trying to scan.

Step By Step:

1.Open SQL management studio (start-programs...)
2.Authenticate with ur windows id (select server type as Database Engine)
3.Click Databases-->ksubscribers
4.Click NewQuery (found below File)
5.The following is the Query you have to run in SQL Management studio:

Use ksubscribers
update users
set maxsnmpThreads = 4
WHERE agentguid=

6. You will get the agent guid under Agent tab--> Machine status-->Agent status-->select columns-->add Agent GUID (if not there on your environment)

Where Agent GUID is the GUID of the machine where you are running LAN watch scan

7. In the Query simply put "WHERE agentguid=XXXXXXXX" on that system with out the "<>"

Tried this no use.

Executed the SNMP walkthrough script No use
When I go to get files Nothing happens -->three test files come there returning 0KB each

Restarted both SNMP and SNMP Trap services several times on that machine --no use

Please suggest what else I can do to make kaseya understand an SNMP device in my N/W.

Legacy Forum Name: Monitor Sets,
Legacy Posted By Username: rajendra

drodden

Unfortunately I don't have access to it at this point and couldn't give you any info, but it didn't stop the flood of SNMPGET commands, just lessened the load they placed on the processor. There is a SQL query you can use to limit the number of concurrent threads that are opened. Unfortunately, I don't have that either at this time but I may be able to dig it up for you. I believe it exists on the forums somewhere, but may also be available via standard support. I believe it can also be adjusted in the KaseyaD.ini file for an agent. The line 'SNMPConcurrentThreads' has a default value of thirty, and Kaseya recommends changing this to 5. The SQL query allows you to change this from the backbone, but you could easily write a script in Kaseya to query the contents of that file and change any values of 30 to 5. Unfortunately, with the original SNMPGet process, 5 threads still caused the CPU to peg.

1 Thread is even enough to cause the cpu te peg. The problem lies in Net-SNMP, and the way how kaseya is programmed.

Legacy Forum Name: Monitor Sets,
Legacy Posted By Username: KCBeuningen