iMC stopped receiving SMNP Traps after server update.

[Matteo_Gastaldo]

Hi,

I'd like to bring this up to you.
One of my customer recently updated his Windows Server 2019 with the KB you see in the atached screenshot (problem started with the 11/02/2020 update); since then, the IMC stopped receiving SMNP Traps and so there are no more logs about the monitored devices.

When this happened, the server was running IMC Version 7.3 E703. We upgraded to version 7.3 E705P2, but the issue persisted. 

If I type a netstat -an on a CMD, the port 162/UDP is on listening status.
If you could give me some hints on this, It would be awesome;

Thanks in advance,

Matteo

[jguse]

Hello Matteo,

There aren't any known issues I'm aware of related to not receiving traps on these versions, but you could check the status of the imcfaultdm process in iMC Depoyment Monitoring Agent. That's the process in iMC which receives and processes the traps and respective alarms. Is it started up and running stable?

Most issues with receiving traps altogether happen either due to Windows Firewall (or some other firewall) blocking the port, or the process I mentioned above not starting. This is usually due to conflicts on port 162. For example if the Windows "SNMP Trap" process is running on the iMC server, it will use port 162 and block imcfaultdm from starting up as it uses that port to listen for traps. If it's an issue with that port being blocked, you can see which other process is using the port with netstat -abo output.

Hope that helps.

[Matteo_Gastaldo]

Hi jguse,

thanks for you reply.
imcfaultdm process is up and running fine. 

Windows Firewall is disabled on the server, so I'll exclude any issue related to it. I'm not 100% about the port not conflicting with other services, I'm going to check it tomorrow and report as soon as I can here.

Edit 18/02/2020: The port is correctly listening and binded to process imcfaultdm.exe.

I have another update on the case: the IMC received an alarm yesterday, but since than there was no other alarm recorded, even if the customer tried to intentionaly unplug a patch from the switch. 
I noticed that the alarm received is form a device poll by the imc, not by a Trap.