Solar winds device tracker doesn't make sense

The back end tables of UDT are chaotic. The simplest way to think about it is that UDT is collecting a slice of data from at least 3 completely different types of sources, and to make it worse each of those sources is on a different polling schedule so "latest" data from one might not be latest anymore when comparing against a different source. Those sources don't actually have a consistent common thread between them so UDT is rely on a lot of "best guesses" to glue them all together.   Simply put, just because UDT has associated an IP to a user or a MAC address, under the covers they are treated as 3 completely separate tables of data that are filled in as best they can be with the vague hints that are given from several different sources.  Then based on what clues it has it tries to infer the relationships between them, but it's far from reliable.  It worked a lot better in the early 2000's when all users were hard wired to a physical switch port on an exclusively Cisco network, but as we moved into the era where most environments are using multiple vendors for various roles, and nearly all users are on wireless connections and the servers are virtualized it chipped away at the accuracy and usefulness of the relationships.

The Domain controller events provide us a list of users and the IP they logged in from, but thats potentially a different list of IP's than what we might see from a router ARP tables.  So if you see an IP address that has no user data, that means it probably came from ARP and doesn't happen to have a correlating DC login event.  If you see an IP that does have user info but nothing about connected routers then thats a clue that it showed up from the DC events and we arent talking to the router that covers those IP's.  That's just one example of discrepancies and gaps you run into.

The MAC addresses info comes from routers and switches, nothing in the DC events records MAC info, so any user data you see when you look at a MAC is the best guess comparing a Mac table to an ARP table to a windows event log, there are several layers here that may or may not agree about what's going on or when it happened.  

The key thing to keep in mind is that when you are on an IP address object looking at related users or MAC's or hostnames they are really 3 separate things, and the UDT UI is guessing at relationships between them.  I would say the MAC objects are useful when looking for things that really are hard wired to a switch, for any other scenario I don't trust them.  And particularly I don't put a lot of stock in the "last user login" fields since the data collection interval for each object type is typically up to 30 minutes. I can't really compare router info from 20 minutes ago to the switch info from 5 minutes ago and trust them to agree.

In case you are curious to see all the types tables UDT polls from SNMP to come up with these guesses it is about 3/4 of the way down this page under UDT Information

solarwindscore.my.site.com/.../List-of-NPM-NTA-VNQM-MIBs-and-OIDs-used-for-Polling

That is an unexpectedly detailed answer, thank you very much for taking the time to provide it. 

Does this mean this can only be used to improve your guesswork, I've found for directly connected devices it's been fairly reliable, be it an office AP of switchport. 

Indirectly connected is a different question by the looks, what I don't understand though the Mac Address is unique, that should not change no matter when it was polled in relation to the machine name, as yet If I search for an mac address it shows the wrong machine

lastly I can see what you're saying about the 3 resources, can it be tightened up to less that 30 mins or is that going to cause a lot of traffic, I'm assuming with over 1000 machines it's going to be quite a lot of data. 

I've never tested tightening up the interval,  it could help but as you indicate you might want to test how your network behaves under the increased frequency.   Some devices can get kind of fussy if they have larger mac tables to send.  The usual form of headache would be the cpu of the management plane maxing out for a few seconds while it processes the snmp request.  If that is the case with your devices then you'd see them doing that now even with the slow polling,  but if you go faster it becomes a more common event and some people or devices don't like that. 

I would be nice to have a view on CPU usage when it comes to polling, I'm set to the defaults above but I don't see any way to gauge if a change to that will show an improvement or not, not way to measure it. I can see for devices that are in the office for a few hours on wireless, or cable, the information is far more accurate. for people that work in the office then remotely the next day, it's all over the place, it feels like it needs to operate like DNS aging and have the ability to remove the stale stuff more frequently. 

Out of interest, have you witnesses more issues when using UDT over AOVPN? on prem seems to be really good but the issues seem to appear with anything over VPN

Out of interest, have you witnesses more issues when using UDT over AOVPN? on prem seems to be really good but the issues seem to appear with anything over VPN