Network Management

Troubleshooting - Guide To UDT Customer Issues

This document will serve as a guide for troubleshooting UDT issues. It provides guidelines how to solve the most common UDT issues so you can resolve them without the necessity of generating a ticket and working with support. It also gives an insight into UDT Compatibility Checker and UDT logs and how to use those data effectively.

First published date

10/31/2018 6:02 PM

Last published date

1/31/2026 12:23 AM

Overview

This document will serve as a guide for troubleshooting UDT issues. It provides guidelines how to solve the most common UDT issues so you can resolve them without the necessity of generating a ticket and working with support. It also gives an insight into UDT Compatibility Checker and UDT logs and how to use those data effectively.
Basic knowledge of UDT is highly recommended as well as to read this document several times because some chapters become more clear later.

Product section

User Device Tracker

Resolution

Please note the following for SQL queries below:

-- Scripts are not supported under any SolarWinds support program or service.
-- Scripts are provided AS IS without warranty of any kind. SolarWinds further
-- disclaims all warranties including, without limitation, any implied warranties
-- of merchantability or of fitness for a particular purpose. The risk arising
-- out of the use or performance of the scripts and documentation stays with you.
-- In no event shall SolarWinds or anyone else involved in the creation,
-- production, or delivery of the scripts be liable for any damages whatsoever
-- (including, without limitation, damages for loss of business profits, business
-- interruption, loss of business information, or other pecuniary loss) arising
-- out of the use of or inability to use the scripts or documentation.

UDT Compatibility Checker

This chapter describes the UDT Compatibility Checker tool, what it can do, how to use it and how to collect data for investigation by dev team.


Introduction 

UDT Compatibility checker is a standalone GUI application which polls selected device(s) for data – but presents the results in a raw format which is much more suitable for investigation when something is not the way you expect. The UDT compatibility Checker is located in <Install Directory>\SolarWinds\Orion folder and is named SolarWinds.UDT.Checker.UI.exe.
 


How to scan a device 

To poll some device for data click the New button. This opens a wizard that guides you and where you configure what device to poll and what data to collect. 

On the first screen you must choose whether the device you want to poll has already been added to Orion as node or you want manually setup the device. Optionally you can specify a session name which is useful in case you are going to scan multiple devices.

 


Orion Node 

When you select Orion Node option, the next step will ask you to enter credential (User Name and Password) to log on to Orion server.

Next you must select the node you want to poll. The nodes are filtered according to the polling method specified in Orion (SNMP, ICMP or WMI).

 

In the last step you can select what data you want to collect from the device. 

When you click on Finish button, the selected UDT job(s) will be executed against the device and collected data displayed.


Enter manually 

When you select Enter manually option, the next step will ask you to enter IP address of the device, credential type and vendor. Credential type is either SNMP1, SNMP2c, SNMP3 or REL and it specifies the protocol used to communicate with the device. Vendor is either Cisco, Juniper or Other and it specifies whether to use some proprietary (not standard) OIDs to get the data.

The next step differs based on the credential type you selected – for SNMP1 or SNMP2c enter community string, for SNMP3 enter user name and context, and for REL enter user name and password to access remote event log. 
The last step is the same as in the Orion Node option where you select what data you want to collect from the device. 
When you click on Finish button, the selected UDT job(s) will be executed against the device and collected data displayed.


How to analyze the results 

The data returned from the device differs based on the selection in the last step of the wizard though the overall idea how the data are presented is the same.


Discovery, Layer2, Layer3 and DNS results 

In the Session Data menu you can find some items with Job Statistics suffix. If you select one of those, it will display an overview of the selected job where you can verify how the device responds to UDT requests for specific OIDs (Type and Status) and how long it takes (Duration). This way you can easily identify if the device is currently not supported by UDT or it timeouts on some requests. 

The other items in the Session Data menu give a detailed information about the selected object (OID) and what data it returned. The item always belongs to the nearest Job Statistics parent above. 
Below is a very brief description of some of the objects UDT query to get the data. To get more details and understand what the individual values mean you may use the Cisco SNMP Object Navigator.

 

Discovery/Layer2 Job Statistics 

These two jobs are very similar in what OIDs they query. 
Following objects contains data about ports (port index, name, ifType, speed, trunk mode etc.). In case UDT displays port data you believe are incorrect, this is the place where to look.

  • ifTableInfoCols
  • ifxTableInfoCols
  • dot3StatsDuplexStatus
  • dot1qVlanCurrentTable
  • vmMembershipSummaryTable
  • vlanTrunkPortDynamicStatus


Following objects contains data about endpoints (MAC addresses) and what ports are those endpoints connected to. In case UDT doesn't display some endpoint, this is the place where to check how the device returns the MAC address.

  • dot1dTpFdbTable
  • dot1dBasePortTable


Layer3 Job Statistics 

Following objects contains data about endpoints (IP addresses) and their mapping to corresponding MAC addresses. In case UDT doesn't display some IP address, this is the place where to check how the device returns the IP address and what is the IP-MAC pair.

  • ipNetToMediaTable
  • ipNetToPhysicalTable


If the device doesn't support those objects, UDT can't get any layer3 information.


DNS Job Results 

This is a simple list that displays IP addresses obtained by layer3 job and results of resolving them into DNS names.
 

 

Users results 

The results for users (REL job) are presented in a slightly different way. To get data from domain controller UDT tries three different channels – Eventing6, Eventing5 and WMI. Usually only one channel returns some data so you can ignore any error messages for the remaining two. 

 


How to save the results 

Data from UDT Compatibility Checker are essential for the support team when investigating any issue that happens only on some specific device so it's better to provide as much data as possible. There are several ways how to save the data:

  • Live Log – when you click the Live Log button, a new window with textual output opens. You can simply copy/paste the text into a file or click the Save button.
  • Current Session into File – save the selected session
  • All Sessions into File – save all selected sessions
  • All Sessions into Diagnostics – the file will be saved into \SolarWinds\Logs\Orion folder and will be automatically picked up when diagnostics are collected (the easiest and preferred option)


Node data overview 

UDT Compatibility Checker offers another feature that is very useful in case you need to compare results with data in UDT. 
When you click the '…' button in the Session Properties section the Node Viewer dialog appears where you can see all data UDT Compatibility Checker collected in much more user-friendly way – discovered node capabilities, properties of all ports, how many and what endpoints are connected to each port and a lot more.


UDT logs 

This chapter describes the UDT logs, what data are saved on different logging levels, how to use those data to identify possible issues, and how to collect data for investigation by the support team.


UDT Jobs 

This log file (C:\ProgramData\Solarwinds\Logs\Orion\UDT.Jobs.log) contains information about execution of all UDT jobs. The default logging level is set to info which is sufficient to determine whether given UDT job runs and finish successfully or there is some issue.


Info 

With logging level set to info the log shows the job started/finished together with duration and job type. In case you need to verify execution of specific job, search for the job's node IP address and then find the right job type. If you notice suspiciously high job duration, it's worth to investigate (see UDT Advanced Settings chapter for more details). If you take closer look at the UDTDnsJob, the job still finished successfully but there was an error trying to resolve the IP address to DNS name. Probably the DNS server doesn't know this IP address which you can verify running nslookup command.


Debug 

With logging level set to debug the log shows a lot more information which may become quite overwhelming (especially for discovery, layer2 and layer3 jobs). 
For REL job the debug shows some important information:

  1. These four values refer to configuration of the REL job. The first value stands for the channel to use (Eventing6, Eventing5 or WMI). In this case Any means UDT will try to use all available channels to. The second value stands for current index in the remote event log file. Index of -1 is supplied only for the first poll and it means UDT will use time frame instead, but on any subsequent polls there will be last read index. The third value is important only for the first run after business layer restart or when node goes to managed from unmanaged. After that UDT relies on last read index. So 30min means UDT will get only events from 'now' to 'now – 30 minutes' time frame. The last value stands for the REL job batch size.
  2. This information tells you that UDT was able to connect to the domain controller and read the security log.
  3. Here you can see how many events were those UDT collects. In case you see returning '0' event log entries it may be worth to check the security log on the domain controller if there are any relevant events (4768, 4769) and what's their date and time.


For discovery, layer2 and layer3 job the debug shows results of all SNMP requests which may be thousands of lines. This information is very important for investigation of device specific issue by dev team. Unfortunately when there are other jobs running, the log file gets immediately overwritten. So to have usable debug logs for some node's jobs, it's very important if all other nodes get temporarily unmanaged. This will stop all other jobs so the log file really contains debug information only for the particular job(s). 

Verbose 

Usually it's not necessary to set logging level to verbose. Discovery, layer2 and layer3 jobs will additionally log the output formatted as xml which is then passed into business layer. Exception is REL job which in verbose logs all entries read from the security log. This may be helpful.


UDT Business Layer 

This log file (C:\ProgramData\Solarwinds\Logs\Orion\UDT.BusinessLayer.log) contains information about everything that happens inside the business layer, be it either processing job's results, changing node's state or loading data for resources. The default logging level is set to info which is not very suitable for investigation. So in most cases it's necessary to change the logging level.


Info 

With logging level set to info probably the only useful information log shows is about UDT discovery. This is a good starting point in case customer states discovery takes too long, it doesn't import all devices or you simply need to know configuration of the discovery. 


Debug 

With logging level set to debug the log shows details about processing job's results – what ports were imported, what MAC and IP addresses were discovered, what users were updated and a lot more. Business layer log in debug is essential for dev team.
Very easy way how to find what you need in debug log is to search for "N:[NodeID]" string and then just look for the right job type.
 


Verbose 

Usually it's not necessary to set logging level to verbose as it additionally shows only the data that are being processed.


UDT Jobs Runtime Stat 

This log file (C:\ProgramData\Solarwinds\Logs\Orion\UDTJobRuntimeStat_JobRawStat.csv.log) contains statistical information about execution of each job. This is very useful if you need to find if specific job fails periodically or always at certain time, if there are any jobs with high duration (possible timeouts) etc
. 


Device Tracker Advanced Settings 

This chapter describes some of the options on UDT Advanced Settings page and what impact they have on UDT. Also several options that are not adjustable through UI are mentioned.


UI adjustable settings 

Device Tracker Advanced Settings page is accessible from User Device Tracker Settings page. When you change some setting on this page, the change will take effect immediately (or on nearest poll). These changes don't require restart of business layer service.


Port/Layer3 Discovery Job Timeout 

In case UDT discovery fails on some device and you notice timeouts in logs, increasing this value may help. It may happen that some device is slow in responses or is overloaded by SNMP requests from other modules.


Layer2/Layer3/DNS Job Timeout 

In case you notice some job in UDT.Jobs log with high duration and this error in UDT.BusinessLayer log most likely the job didn't finish before specified timeout.


If current Layer2 Job Timeout value is set to 30 minutes (i.e. 1800 seconds), you know why the job was canceled. Increasing the timeout will probably solve this issue.


DNS Cache Positive TTL 

If UDT successfully resolves an IP address into hostname, this value tells how long UDT won't try to resolve the IP address again. In case you have an environment where endpoints (PCs) change their IP addresses frequently, it may happen that UDT will report wrong (old) hostname for some IP addresses. Decreasing this value may help to keep the data actual.


DNS Cache Negative TTL 

If UDT fails to resolve an IP address into hostname, this value tells how long will UDT wait before next attempt.


Database only settings 

There are some settings that are not adjustable through UI but must be directly modified in database. All UDT settings are stored in UDT_Setting table that is very simple. Business layer service restart is required when you change some setting manually. 


UDT.RemoteEventMaxAgeMinutes 

This setting has impact on the time frame from which REL job tries to read the events from security log on domain controller. Default value is set to 30 minutes which means UDT will try to read events from 'now' to 'now – 30 minutes'. This value is used only for the first run of REL job, for the first run after business layer service restart or when node goes to managed from unmanaged.
This setting is not present in UDT_Setting table by default, you must insert it manually. 
You can use this setting in case customer needs to get larger history of user log on events.


UDT.GetUserInfoThroughWMI, UDT.GetUserInfoThroughWMIForEventing6 

Please see Cross-domain UDT polling document for more details.


Common issues 

This chapter describes some of the most common issues we have seen which repeat frequently. Below is a brief description of each issue together with some suggestions what to check, what can be possible cause and how to collect all necessary data for dev team.


UDT Discovery 

You are not able to run UDT Discovery or it fails on some specific device while others are scanned successfully.


Discovery fails at all 

In case UDT Discovery fails no matter what devices are selected, there are several possible reasons:

  • UDT Discovery always runs on main poller even if the nodes are affiliated with additional poller. Make sure the machine where main poller is installed has access to the selected device (try ping etc.)
  • Make sure the SNMP requests/responses are not blocked by firewall
  • Verify that job engine services (JobEngine v2, Collector Polling Controller, Collector Data Processor, Collector Management Agent) are running
  • Verify UDT.Jobs log to see if the discovery job finished successfully or some error occured
  • Verify UDT.BusinessLayer log to see if the discovery job's results were processed successfully or some error occurred

 

Data for support investigation 

If you notice some errors or exceptions in UDT logs, collect diagnostics. If the logs look like everything is fine, please do following:

  • Set UDT Business Layer and UDT Jobs logging level to debug and re-run UDT Discovery
  • Run UDT Compatibility Checker (discovery target) against any device and save the results
  • Collect diagnostics

 

Discovery fails on some device 

In case UDT Discovery fails only on some specific device while on others it finishes successfully, there are several possible reasons:

  • UDT Discovery always runs on main poller even if the nodes are affiliated with additional poller. Make sure the machine where main poller is installed has access to the selected device (try ping etc.)
  • Run UDT Compatibility Checker (discovery target ) against the device and check the results
  • Increase Port/Layer3 Discovery Job Timeout (Advanced Settings page)
  • Increase SNMP Timeout (Advanced Settings page)


Workaround 

In case UDT Discovery still fails but UDT Compatibility Checker shows that layer2/layer3 polling of the device works correctly, there is a way how to bypass UDT Discovery and start polling the device. You can insert the node into UDT_NodeCapability table manually:

  • Run SQL Server Management Studio
  • Adjust following query
    • [NodeID] – ID of the device (node) in Nodes table
    • [Capability] – polling capability of the device, see Appendix A for details
    • [Enabled] – value of 1 means UDT will poll the device
    • [PollingIntervalMinutes] – by default this is the value specified on Polling Interval page (undex UDT Settings)
    • [Options] – see Appendix B for details

 

 

 

Insert into UDT_NodesCapability ( [NodeID],  [Capability], [Enabled], [PollingIntervalMinutes],[Options]) values (1129,2,1,300,0) 



In case device has multiple capabilities (layer2, layer3), insert records for all of them and just change [Capability] value.

  • Execute query
  • Restart business layer and job engine services. This will create and schedule UDT jobs based on the selected capabilities and populate all other UDT tables (UDT_Port, UDT_Vlan, UDT_PortToPort etc.)

 

Data for support investigation 

To help the support team with investigation, please do following:

  • Run UDT Compatibility Checker (discovery target ) against the device and save the results
  • If there is some other identical device (same vendor, IOS etc.) where discovery finishes successfully, please include Compatibility Checker results from this device too for comparison
  • Include what values you tried to set the timeouts on Advanced Settings page
  • Set UDT Business Layer logging level to debug and re-run UDT Discovery for the one particular device
  • Collect diagnostics

 

Missing layer2/layer3/DNS data 

Device has been successfully added to UDT but you are still missing any layer2, layer3 or DNS data in UDT.

 

Missing layer2 data 

In case UDT doesn't display any layer2 data (MAC addresses), below are several ideas what to check:

  • Verify device supports all OIDs
  • Verify layer2 job exists for the node (UDT Job Status page)
  • Verify ports are being monitored (Port Management page)
  • Verify output of UDT Compatibility Checker (layer 2 target), try all versions of SNMP protocol – if one of them succeeds, consider changing device' configuration
  • Verify in UDT.Jobs log the job completes successfully; verify job's duration and adjust timeout if necessary (UDT Advanced Settings page)
  • In UDT.BusinessLayer log verify the job's results are processed successfully
  • Connect to the device and verify MAC address table (e.g. sh mac address-table)

 

Data for support investigation 

To help support team with investigation, please do following:

  • Run UDT Compatibility Checker (layer 2 target ) against the device and save the results
  • In case UDT Compatibility Checker doesn't show any layer2 data (and device' MAC address table really contains some data), SNMP walk of the device will be necessary
  • If possible, temporarily unmanage all other nodes, set logging level for UDT.BusinessLayer and UDT.Jobs to debug, and run the layer2 job manually (UDT Job status page)
  • Collect diagnostics

 

Missing layer3 data 

In case UDT doesn't display any layer3 data (IP addresses), below are several ideas what to check:

  • Verify device supports all OIDs
  • Verify layer3 job exists for the node (UDT Job Status page)
  • Verify output of UDT Compatibility Checker (layer 3 target), try all versions of SNMP protocol – if one of them succeeds, consider changing device' configuration
  • Verify in UDT.Jobs log the job completes successfully; verify job's duration and adjust timeout if necessary (UDT Advanced Settings page)
  • In UDT.BusinessLayer log verify the job's results are processed successfully
  • Connect to the device and verify ARP table (e.g. sh arp)

 

Data for support investigation 

To help dev team with investigation, please do following:

  • Run UDT Compatibility Checker (layer 3 target) against the device and save the results
  • In case UDT Compatibility Checker doesn't show any layer3 data (and device' ARP address table really contains some data), SNMP walk of the device will be necessary
  • If possible, temporarily unmanage all other nodes, set logging level for UDT.BusinessLayer and UDT.Jobs to debug, and run the layer3 job manually (UDT Job status page)
  • Collect diagnostics

 

Missing DNS data 

In case UDT doesn't display any DNS data (hostnames), below are several ideas what to check:

  • Verify layer3 job exists for the node (UDT Job Status page) because DNS job always runs when layer3 job completes
  • Verify output of UDT Compatibility Checker (DNS target)
  • Verify in UDT.Jobs log the job completes successfully; verify job's duration and adjust timeout if necessary (UDT Advanced Settings page)
  • In UDT.BusinessLayer log verify the job's results are processed successfully
  • Verify the machine is able to connect to DNS server and resolve the IP address (e.g. nslookup)

 

Data for the support investigation 

To help the support team with investigation, please do following:

  • Run UDT Compatibility Checker (DNS target) against the device and save the results
  • If possible, temporarily unmanage all other nodes, set logging level for UDT.BusinessLayer and UDT.Jobs to debug, and run the layer3 job manually (UDT Job status page)
  • Collect diagnostics

 

Incorrect layer2/layer3 data 

Layer2/layer3 job is running but data it returns are not correct. Either wrong VLAN, connection type, MAC address, IP address or hostname is being reported for an endpoint.


Wrong VLAN 

In case UDT displays endpoint with VLAN that you believe is not correct, below are several ideas what to check:

  • Connect to target device and check MAC address table

 

Data for support investigation 

To help the support team with investigation, please do following:

  • Provide a screenshot of MAC address table from device
  • Provide a screenshot of UDT resource/page where the wrong VLAN is displayed
  • Run UDT Compatibility Checker (layer2 target) against the device and save the results
  • Collect diagnostics
  • Provide full dump of UDT_PortToEndpoint, UDT_Endpoint and UDT_Port tables (see Appendix C for details)

 

Note 

Keep in mind that VLAN is affiliated with layer2 information (MAC address), not layer3 (IP address).


Wrong connection type 

In case UDT displays endpoint with connection type that you believe is not correct (probably only direct connection type will worry customers), below are several ideas what to check:

  • Connect to device that UDT tells endpoint is directly connected to and check MAC address table
  • Connect to device that customer tells endpoint is directly connected to and check MAC address table
  • Verify the endpoint is not connected to a trunk port; trunk port (UDT_Port.TrunkMode = 1) is excluded from direct port-to-endpoint connections by design
  • Verify the endpoint is not connected to a port acting as trunk (i.e. port with multiple VLANs); if one port has more than two VLANs (UDT_VLAN), it's excluded from direct port-to-endpoint connections by design

 

Data for support investigation 

To help the support team with investigation, please do following:

  • Provide a screenshot of MAC address table from device UDT tells endpoint is directly connected to
  • Provide a screenshot of MAC address table from device customer tells endpoint is directly connected to
  • Provide a screenshot of UDT resource/page where the wrong connection type is displayed; if not visible on screenshot, provide information about the node, port and MAC address so dev team can identify them easily
  • Collect diagnostics
  • Provide full dump of UDT_PortToEndpoint, UDT_Endpoint, UDT_Port , UDT_VLAN and UDT_PortToPort tables (see Appendix C for details)

 

Wrong MAC address/IP address/Hostname 

In case UDT displays IP address for MAC address, hostname for IP address etc. that you believe is not correct, below are several ideas what to check:

  • Connect to device and check ARP table (to verify IP address for given MAC address)
  • Run nslookup (to verify hostname for given IP address)
  • Keep in mind that Ports Details resource on Node Details page displays only active data
  • Keep in mind that Endpoint Details page displays active and historical data (.e.g. Endpoint Details resource may show IP address for MAC address endpoint that is not displayed in Ports Details resource)
  • Pay attention to filter options on Ad-hoc Reporting page

 

Data for support investigation 

To help the support team with investigation, please do following:

  • Provide a screenshot of page/resource that shows wrong data
  • Provide a screenshot of ARP table/nslookup result
  • Clearly state what data is wrong and what is correct value (MAC address, IP address, hostname)
  • Collect diagnostics
  • Provide full dump of UDT_PortToEndpoint, UDT_Endpoint, UDT_IPAddress, UDT_DNSName tables (see Appendix C for details)

 

Device high CPU utilization 

CPU utilization on target device goes very high on every UDT poll. This may become more urgent issue when other modules are polling the device too. There is SNMP Pacing Delay setting on Advanced settings page to address this issue. Usually changing value from 0 to 1 or 2 is enough to lower CPU utilization. However this setting affects all UDT jobs so it may increase their execution length.

  • Adjust SNMP Pacing Delay value
  • If possible, try changing device to SNMPv1 as some devices can't handle GetBulk requests well
  • Check length of SNMP queue on device
  • Run UDT Compatibility Checker (layer2 target) against the device using SNMP v1, v2, v3 and observe CPU utilization during that time

 

Data for support investigation 

To help the support team with investigation, please do following:

  • Collect diagnostics and provide results of steps mentioned above

 

Missing user data 

UDT doesn't display any user data. There are several possible reasons and below are some ideas what to check.


Valid credential 

To display user data UDT reads security log from domain controller and parse its content. To access this security log you must provide valid credentials with sufficient rights to UDT.

  • Verify account supplied to UDT has access to security log on domain controller
  • Verify the credentials are successfully tested (go to Add Node wizard, enter IP address of domain controller, select Active Directory Domain Controller option, enter credential and hit Test button)

 

Events in security log 

In case credentials used to pull data from domain controller are correct but UDT still doesn't display any user data, verify the content of security log on domain controller.

 

No user data 

In case credentials used to pull data from domain controller are correct and security log contains correct events but there are still no user data or only some users displayed in UDT.

  • Connect to domain controller and check create date and time of events 4768/4769; on first poll UDT pulls only events not older than 30 minutes by default
  • Verify output of UDT Compatibility Checker (users target)
  • Verify in UDT.Jobs log the job completes successfully
  • In UDT.BusinessLayer log verify the job's results are processed successfully

 

Data for support investigation 

To help the support team with investigation, please do following:

  • Run UDT Compatibility Checker (users target ) against the domain controller and save the results
  • Set UDT Business Layer logging level to debug and re-run REL job for the particular domain controller
  • Collect diagnostics

 

Changing channel 

One of the most probable reasons why UDT doesn't display any user data is that wrong channel is used for DC polling.
There are several channels UDT uses for DC polling. Those channels are Eventing6, Eventing5 and WMI and they are used in that order. If any channel succeeds, UDT doesn't try another, and this is the problem. It may happen that e.g. Eventing5 channel will report 'success' but doesn't return any data, but data are returned by WMI channel which is not attempted (previous channel succeeded). 
If you run UDT Compatibility Checker against the domain controller and see Eventing5 didn't return any data but WMI did you need to force UDT to use WMI channel instead of Eventing5. This is done by adjusting UDT_NodeCapability.Options value (see Appendix B). 
Following update will change Options value for given node (adjust NodeID): 

Then go to Node Management page and unmanage/remanage the node – this will reschedule jobs for the node and REL job will now use WMI channel instead of Eventing5.
 

 

Stale Data or not Polling when everything looks Ok 

There maybe Stale UDT job data either in the table or in the SDF's the steps below will help clear these out and rebuild the jobs. 

 

NOTE: After following the steps below it can take some time (several hours to possibly a day) for all the UDT jobs to rebuild and repoll.

 

  1. From the Orion Server, stop all Orion services via Orion Service Manager.
  2. Launch Database Manager, Start > All Programs > SolarWinds Platform.
  3. Click on Add Orion Server to connect to the SQL server hosting Orion database.
  4. Expand your SQL Server and look for your Orion Database in bold.
  5. Right click your Orion Database and click on New Query. Run the following query:

          

  Truncate Table UDT_Job

 

  1. Press Execute Query.
  2. Restart the Orion Services.

 

Summary 

Although each issue is unique, experience shows that quite a lot of issues repeat or are very similar. It's not possible to make a perfect guide for every situation but hopefully this document will give you some ideas how to solve those issues.


Appendix A – Node Capability 

The value in UDT_NodeCapability.Capability defines what data the device can provide, i.e. what type of UDT job will run for this device. One device may have multiple capabilities. The device' capability is determined during UDT discovery. 
Capability:
'2' – UDT layer2 job will be scheduled to poll layer2 data (MAC addresses)
'3' – UDT layer3 job will be scheduled to poll layer3 data (IP addresses); this also includes IP-to-DNS resolution (DNS job)
'8' – REL job will be scheduled to poll domain controller for logon events and AD user data


Appendix B – Node Options 

The value in UDT_NodeCapability.Options column depends on the device capability. This value is automatically populated by processing results of UDT Discovery. 
Layer2 capability:
'0' – no cdp/lldp queries
'1' – lldp
'2' – cdp
'3' – both 
Layer3 capability:
'1' – only ipNetToMedia
'2' – only ipNetToPhysical
'0' or '3' – both 
REL capability:
'0' – any that return data with priority Eventing6 -> Eventing5 -> WMI
'1' – Eventing6
'2' – Eventing5
'4' – WMI


Appendix C - Diagnostics 

When collecting diagnostics, not only the logs but also content of selected tables is saved.  
Each module defines what tables and data are being collected by own configuration file. For UDT this is defined in \Program Files\SolarWinds\Orion\UDT\UDT.Diagnostics file which is a simple XML: 


Notice the <database> tags which define SQL queries and files where to save the results. Most queries limit results to first 10000 rows, so in cases where dev team needs all data for investigation, it's necessary to check all content of important tables was exported. Inside the diagnostics archive is a handy file (\DBInfo\TableRowCounts.csv) where you can find total number of rows for each table:
 


So if you see some table has more than 10000 rows, the diagnostics will contain only
portion of all data and most likely it won't be usable for investigation. Tables where this really matters are UDT_NodeCapability, UDT_Port, UDT_PortToEndpoint, UDT_Endpoint, UDT_IPAddress, UDT_DNSName and UDT_PortToPort. There are two ways how to get all necessary data:

  1. Remove 'top 10000' clause from the query and collect new diagnostics. Exception is UDT_PortToEndpoint table which can be really big. In that case it's better to export this table manually from SQL Server Management Studio.
  2. Adjust the queries to gather only data for specific endpoint (MAC, IP or DNS). This however requires some knowledge of UDT database schema. Below is an example how to collect data for specific MAC address which should give you an idea how to create your own diagnostics' queries:


Providing right data to the support team for investigation can save couple of days!