In case you haven’t heard yet, we have just announced a new product, User Device Tracker. This product helps you quickly find where a machine is connected in the network. We sometimes get questions about the difference between our other solutions for device tracking. To read more about that, see my Finding where devices are connected in your network. We have had a very positive response from our early adopters and testers. Some of the requests we’ve received are things we are working on building into the product, but I want to take a moment to share with everyone some of the more handy tips and tricks.
1. Change the type of interfaces that count for capacity
By default, UDT will use the following types of interfaces for capacity analysis: ethernetCsmacd(6), propPointToPointSerial(22), ppp(23), propVirtual(53), propMultiplexor(54), fibreChannel(56), fastEther(62), fastEtherFX(69), channel(70), gigabitEthernet(117), hdlc(118), l2vlan(135), l3ipvlan(136), pos(171). If you want to change this so that you will collect interface types that you are interested in tracking capacity for; delete the node (if you already added it), stop the Orion Module Engine service, modify the SolarWinds.UDT.BusinessLayer.dll.config file and update the UDT.MonitoredIfTypes values to include only the types you are interested in.
For example, the list of ifTypes can be changed from this initial list, to this second list:
<add key="UDT.MonitoredIfTypes" value="6,22,23,53,54,56, 62,69,70,117,118,135,136,171" />
<add key="UDT.MonitoredIfTypes" value ="6,56,62,69,70,117" />
After you update the list, you will need to start the Module Engine service and re-add the nodes and relevant ports. You capacity analysis charts should now include only the IfTypes you are interested in.
2.More custom reports
UDT only has 1 out of the box report. Yes, we realize we need to do more. However, with all of the exciting new data we are collecting, customers are anxious to get access to it. Our developers have put together a few custom SQL reports and I placed them on the content exchange. In the future we would like to fully extend the schema so that these types of reports are easy for customers to modify and run on their own.
3. Finding machines with suspicious hostnames
UDT has a feature called the Watch List. The Watch List allows you to specify a machine that you are interested in keeping an eye on (maybe it is lost, or a recurring problem machine). You can quickly see where all of your Watch List items are connected in the network by looking at the list, or you can schedule a report to be sent daily so you can see when one of these machines connects to the network. Some people are excited about the potential for this set of use cases for rogue detection or unauthorized computers on the network. A quick (read hack) way to do this is to create a Custom SQL Report that looks for a specific pattern to match. For example, if I know that all of the computers at SolarWinds should start with “Solar”, I can create the following custom SQL report for all endpoints that DO NOT start with “Solar”:
select * from UDT_DNSName where UDT_DNSName.DNSName not like 'Solar%'
4. Integration with NPM and the difference between a port and an interface
Out of the box for v1, we wanted to have tight integration with our existing products. UDT can be installed completely independent of any other products, or it can be installed like a module with NPM. When it is installed with NPM, it will use the same database and you can simply run Port Discovery on the nodes you are already managing in NPM. Several resources are added to the Node Details View: Ports Currently In Use on Node Name, Port Details, and Ethernet Ports Used Over Time. If you install UDT standalone, you will still get these resources, but if you install with NPM, you get the benefit of being able to have the Network Management, Connection, and Capacity Analysis information all on one screen. You may then notice that there is a Port Details resource in addition to the Current Percent Utilization Interface table. This begs the question, what is the difference between a port and an interface? This is primarily a naming convention to make it easier to keep separate the different way these are licensed. An interface is an NPM construct that we collect utilization information about (bytes in/out, percent utilization, errors and discards, etc.). The interface impacts your NPM license count. A port is a UDT idea. When you have a monitored port, we will collect connection and capacity analysis information about that port and it will count against your UDT license. Here is a quick side by side graphic of the difference between ports and interfaces.
Some users get concerned when they learn they need to monitor all of their ports in UDT. This does not impact their NPM license at all. Take the example when you are monitoring the uplink interfaces in NPM on one 48 port switch. This should be 1 node license and 2 interfaces. When you add UDT, you will need to add the 48 ports that will count against the UDT license, but your NPM license will still be just the 1 node (since you are already monitoring the node) and 2 interfaces.
5. Deleting versus un-monitoring ports
This is more of a clarification for users who want to better understand the difference between deleting a port and un-monitoring it. Well you can’t actually delete a port in UDT (don’t worry, we’ll get this fixed in the future). If you want to permanently delete a port, you need to delete the node, the rediscover the ports and only select the ports you are interested in. If you select a port to unmonitor, we will not collect connection information (and it will not count against your UDT license), but we will still count it for capacity purposes.
For more information about UDT and to download a free 30 day eval, go here: User Device Tracker.