This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

UDT Alert Issues

I recently reinstalled UDT upgraded to 3.4 to attempt to meet a use case requirement where we want to know when a new MAC address appears on a specific device type. I used the canned alert "Alert me when a new MAC address appears on network" as the template and changed it up to use a Primary and Secondary Section. On the primary I used the Node object and on the Secondary I used the "New MAC Address" object. This allowed me to limit the device type but, the alert email action does not have the variables available to provide the pertinent MAC information to provide for a meaningful alert email without several custom SQL/SWQL calls. Not a big deal but, I'm just not a fan except in very special cases. I also inverted this selection as another test but, I'm finding that the alerts reports other device types as well.

Another option I tried was to set the Trigger condition based on a Custom SWQL against the "New MAC Address" object. This is the only one that seems to actually suppress the other object types.

SELECT NewMACAlert.Uri, NewMACAlert.DisplayName FROM Orion.UDT.NewMACAlert AS NewMACAlert

JOIN Orion.Nodes N ON NewMACAlert.DeviceID = N.NodeID

WHERE N.Vendor = 'Meraki Networks, Inc.'

This allowed me to get many of the needed MAC attributes in the alert but, not the port name or any of the Node attributes...like which switch is this occurring on. Again , I employed a custom SQL/SWQL joining the two tables.

Consider that all of the Meraki devices have been discovered in my environment for over a year, and UDT has been installed now for over 30 days.

These are the issues I'm having with any approach:

The only thing that seems to work to limit the scope to a specific vendor is the Custom SWQL trigger

Why is there a Port ID = -1 in the NewMACAlert

At a 1 minute "Evaluate the trigger condition" I'm getting flooded with emails.

          How long is something New?

          What exactly constitutes New

          Why do I get duplicate alert emails every minute?

          Why/How can I have more then one MAC on a port with the same last seen time?

          Many times the email comes back and instead of the value that should have been retrieved from the custom SWQL, the query itself is returned

  • What exactly constitutes New


    - Anything that is not part of the UDT Port History.  By default, the retention settings is set to 30 days, so if the endpoint is not detected by that time, it would be detected as new the next time it is scanned by UDT
             
    Why do I get duplicate alert emails every minute?

    - Check the alert itself

             
    Why/How can I have more then one MAC on a port with the same last seen time?

    - It could be indirect connections or it could be device that are on piggybacked like VOIP phones and workstations
             

    Many times the email comes back and instead of the value that should have been retrieved from the custom SWQL, the query itself is returned


    - That means it doesn't find those values.

  • I'm running into a similar issue, in my case management wants me to update the rogue device email alert so that it includes the name of the network device where the rogue device was detected. However, the alert action just doesn't have anything selectable for this to add, and when I attempt to manually add variables like ${NodeName} or ${N=SwisEntity;M=Caption} that work fine on other reports or alerts, here they're ignored.

    This has been a source of frustration not just with UDT, but SolarWinds in general, as it seems that certain alerts and reports only allow certain variables. So there appears to be no way to make them work unless you're some sort of SolarWinds scripting god, and even then I'm not sure it's possible. I've been able to create workarounds for a number of requested reports, where the results aren't exactly what I want but are 'close enough'.