I think there's something else going on. How do you know that Spectrum is the application that is listening on UDP/161? If you have a utility or command, can you send the output?
I don't think it's odd at all that you are running the SNMP service, I just know that the SpectroServer does not listen on UDP/161. I think there is another problem here. Could you provide the output that shows spectrum listening on UDP/161? Now, I could certainly see if some process was listening on UDP/162 and spectrum having an issue with that. If that is the case, do you have a need to use UDP/162 other than spectrum. I could see that causing an issue, but not port 161. From: Gaines, Reba R [mailto:[email protected]] Sent: Tuesday, October 19, 2010 12:50 PM To: Michael Votaw - VTI; spectrum Subject: RE: SNMP GRABS SPECTRUM PORTS DURING REBOOT AFTER MICROSOFT UPDATES Here's the scenario. Every Tuesday at 3:00 AM we run windows updates. When the system reboots and comes backup UDP/161 is grabbed by SNMP and UDP/162 is grabbed by Spectrum. SpectroServer won't start automatically. After I manually start it and start OneClick, OneClick will show a major alarm saying that the NCM service is not running when in fact it is. So I have to stop the ncm services and processd restarts it. I have found that if Spectrum grabs both 161 and 162 , the SpectroServer starts automatically and I don't see the major alarm referring to ncm services not running. Si my initial question was how can I get the snmp services to start after Spectrum services have started? Some have asked why I am running Microsoft snmp services in the first place, it's because I am monitoring several other services on that server within Spectrum along with thresholds for memory utilization and disk space; like so, I am monitoring different services across multiple servers where snmp is enabled. Reba R Gaines, MBA/TM Unicenter/Solarwinds Systems Manager Ciber Defense Technology Systems 200 Westpark Drive, Suite 330 Peachtree City, GA 30269 (770) 268-7448 Direct Dial (678) 449-9080 Mobile From: Michael Votaw - VTI [mailto:[email protected]] Sent: Tuesday, October 19, 2010 10:55 AM To: Gaines, Reba R; spectrum Subject: RE: SNMP GRABS SPECTRUM PORTS DURING REBOOT AFTER MICROSOFT UPDATES I would like to put my $.02 in. Unless things have changed drastically, Spectrum never needs to hold UDP/161 open on the SpectroServer, only UDP/162. Spectrum will indeed send requests out to the destination port UDP/161 to poll devices. Spectrum must be able to receive SNMP traps on port UDP/162 and will try to open this port, but should never open UDP/161. Spectrum doesn't include its own SNMP agent on the server unless you put it there. There should be no issue at all with running the Microsoft snmp agent on the same machine as the spectrum server, as long as you don't enable the snmp trap port on the same server (UDP/162). Try running an application like TCPView (http://technet.microsoft.com/en-us/sysinternals/bb897437.aspx ) to know for sure what application is holding these ports open. From: Gaines, Reba R [mailto:[email protected]] Sent: Tuesday, October 19, 2010 6:48 AM To: spectrum Subject: [spectrum] SNMP GRABS SPECTRUM PORTS DURING REBOOT AFTER MICROSOFT UPDATES Importance: High Hello Spectrum Users: Has anyone conquered this issue. We deploy Microsoft updates routinely and like clockwork, SNMP service grabs either UDP port 161 or 162 (sometimes both) before Spectrum can. I've tried telling SNMP to wait for Spectrum services to load first. That work for a while but then SNMP services would start anymore. I had to uninstall it and then reinstall SNMP to get it to work again. Any suggestions? Reba R Gaines, MBA/TM Unicenter/Solarwinds Systems Manager Ciber Defense Technology Systems 200 Westpark Drive, Suite 330 Peachtree City, GA 30269 (770) 268-7448 Direct Dial (678) 449-9080 Mobile * --To unsubscribe from spectrum, send email to [email protected]<mailto:[email protected]> with the body: unsubscribe spectrum [email protected] --- To unsubscribe from spectrum, send email to [email protected] with the body: unsubscribe spectrum [email protected]
