On some of the nodes; polling details section has the next rediscovery date in the past. How can I correct this? I have tried rediscovering and polling those nodes but the date doesn't change. Any suggestions please?
Did anyone find a solution for this? I noticed one node is showing this in my environment.
Likewise, discovered this also today following up recent discoveries that we had 2 diff pollers hang twice recently and SRM not behave.
For this I created the following report and found 12 rows of various rediscovery dates going back 2 years in all. Not sure how bad that really is but raising it with support to be safe and ensure confidence - only checks UP servers polled by SNMP. From my smudge of SQL:
SELECT Nodes.NodeID,
Nodes.Caption,
Nodes.IP_Address,
StatusInfo.StatusName,
Engines.ServerName,
Nodes.NextRediscovery,
Nodes.ObjectSubType
FROM Nodes INNER JOIN Engines on Nodes.EngineID = Engines.EngineID INNER JOIN StatusInfo on Nodes.status = StatusInfo.StatusiD
WHERE ( (DATEDIFF(mi, Nodes.NextRediscovery, getutcdate() ) > 30) AND (Nodes.Status != '9') AND Nodes.ObjectSubType = 'SNMP')
ORDER BY Nodes.NextRediscovery ASC
And for the poller hanging:
Nodes.LastSync,
WHERE ( (DATEDIFF(mi, Nodes.LastSync, getutcdate() ) > 30) AND (Nodes.Status != '9') )
ORDER BY Nodes.LastSync ASC
whilst unmanaging/remanaging did not give them the nudge needed to respond, noticed all 12 were on the same poller and moving them to another poller resolved the issue.
have raised a ticket here anyway as would rather once in and monitored, nodes should not require such checking and action, would prefer that aspect to be carefree
Uninstallation of the the collector and jobenginev2.
Reinstall both services
Run configuration wizard.
This solved the issue for me.
I second this. Some times the SDF files for these services can become corrupt or have something going on with them. And uninstalling/ reinstalling clears this out. Normally it does the trick and restores normal monitoring.
