I have seen the same behavior at times. It seems that if the Switch does not update the information to a "Null" value overtly, "UDT does not update ITS records. That is a theory so far.
What I am seeing is that a device may have been there but is not. So, it is reflected on MANY switch ports throughout the network but those connections have the same timestamp! The question I then have is this: how can a DEVICE be connect to a switch in one location and also be connected to a switch in a location miles away on a different switch at the SAME TIME?!
Pretty neat trick having two or more IP Addresses on two or more switches in two or more locations with the same timestamp.
I hope that SW sees this and can explain what I am doing wrong with their software.
THAT is using your equipment at the extreme if it were to be true.
Depending on what version you have, you may check and see if there are hotfixes out there. Just for v3.3 there are three hotfixes available that fix several things.
I have had a case open with SolarWinds since February for the same problem. For me, HF1,2 & 3 made no difference.
This week I installed the latest version (UDT 3.3.1) in a test environment and have managed to reproduce the fault. I kept it simple by only installing UDT and only added one switch for UDT to monitor. Problem still exists
However, the issue only seems to occur if I configure UDT to create and use a test database on my production Orion database SQL 2012 server . If I configure UDT to use the bundled version of SQL Express 2017 which is part of the UDT 3.3.1 install then the switch ports map correctly.
The DEV team are currently looking into why UDT does not seem to be compatible with my SQL 2012 database instance.
Well, I don't want to hold my breath but DEV have fixed my test environment by replacing some UDT dlls. They are hopefully going to be releasing a Hotfix in the next few days.
i am working on a ticket with CS and Dev right now on this idea.
It seems that it is a problem that UDT sees more than one DIRECT connection.
We will see how this comes out.
1 of 1 people found this helpful
Hotfix 1 for UDT 3.3.1 was released today which fixed this problem for me (on my test build at least). Just need to apply it to my production build next week.
I believe the following 3 posts are all related to the same bug
The Hotfixes and the updates to the software did NOT fix the issue.
UDT seems to not be able to distinguish what is a connection and what WAS a connection. I think it has to do with the way it records the Timestamp in the database.
So far, the tech says "No" but, there are other anomalies that point in that direction.
If you look at the database in the UDT records, you will see timestamps that are hours in the "future" the way the records are kept. UDT has the same apparent problem with User records. Again, I am working with the tech to see what is really going on. I will try to keep all posted as we keep digging.