3 Replies Latest reply on Dec 11, 2012 10:02 AM by RichardLetts

    Avoid the 'U' in User Device Tracker


      While UDT on the whole is pretty good (we wish it would share better with the other Orion modules and leverage things like the Layer 2 and Layer 3 discovery components and vice versa), we haven't had much luck with user tracking and lackluster response from SolarWinds support.  Reading login events from the Windows Event logs of specified Domain Controllers, we quickly discovered that the user tracking component doesn't scale well and suffers from a few idiosyncrasies, courtesy of Microsoft:

      1) The Domain Controllers must be managed with WMI in order to access the event logs.  Bye-bye SNMP interface data since SolarWinds doesn't provide a "Manage with SNMP AND WMI" option yet. Maybe this is a non-starter since Microsoft intends to drop SNMP support from its server platform but nonetheless, problematic if you're storing long-term trending data and discover that it's wiped out when you change from SNMP to WMI.

      2) We are a corporate enterprise of 250+ offices and 14,000+ employees. That means our DCs see several tens of thousands of login events daily. UDT had an enormously difficult time polling and collecting the user information and the logs filled and rolled quickly.  This is partly an issue caused by Microsoft in the way they collect user login information but it means that UDT simply can't scale to large environments. Our sys-admins wouldn't support user auditing turned on for more than a few hours for testing because it made the logs unusable. SW needs to find another way to retrieve this data or provide a better method for collecting and purging the data. SW suggested ignoring logoff events (already set) and setting the logs to overwrite as needed (also already set) so they obviously haven't worked with UDT in a large enterprise yet.

      3) UDT provides erroneous login information, again courtesy of Microsoft. When a user logs into their machine, the machine does a quick 'browse' of its neighbor systems and creates login events on all of those systems. When a user checks their Exchange mail, Outlook logs in to their mail server and creates a login event. When a user connects to a network file share, a login event is created and when a user connects via RDP or Citrix to a remote machine, a login event is created. So which machine did the user really login to?


      While the ability to tie a user to a machine, IP and switchport is welcome and desperately needed, problems scaling and an inability to localize login events means the 'U' in UDT isn't ready for prime-time yet.

        • Re: Avoid the 'U' in User Device Tracker



          I'm sorry you are having these issues but I really appreciate you taking the time to write up the details here.


          1. SAM is working on being able to poll interface data via WMI. The other option is to manage the network side of the interface instead of the server, not ideal for sure.
          2. As you have mentioned, we are currently bound by the data provided by MS. We have discussed other options but that is currently the most reliable (even though it is not as reliable as it should be). One way to solve this problem is to rely on login scripts or agents running on end user workstations. Most users we have talked to have said they prefer the events. What are your thoughts?
          3. There are different login types based on whether a user is logging in interactively or their accounts are being used in network services. What login EventID types were you seeing from Exchange? If someone logs in to a RDP session, I would expect to see that in UDT because a user has logged in to a machine.



            • Re: Avoid the 'U' in User Device Tracker

              1. - good to know, thanks. We avoid monitoring system interfaces in general as well as all of the end station switch ports primarily due to the amount of data that would be generated. We add computer interfaces to Orion for troubleshooting purposes as needed. The lack of SNMP causes other issues like loss of custom pollers so being able to choose certain stats from WMI and others from SNMP would be helpful.

              2. While management agents can be heavy and an administrative hassle, they can provide access to host details which aren't accessible via any other methods. Since you're at the mercy of MS with logon events, I'd try to capture the information at the user side so we wouldn't be adverse to trying an agented model.

              3. We can send you screenshots of what UDT picked up in a login; it definitely interpreted network browsing after login as valid logins. Exchange is logging 4768/4769 events but I haven't been able to track down the user that showed that specific login yet.

              • Re: Avoid the 'U' in User Device Tracker

                How about an agent on the domain controller capturing the login events and forwarding those to the server?

                Then you could expose that API to enable customers with non-AD controllers to forward login events from other systems (e.g. Shibboleth, Radius).