The goal of UTLite in CM 5.0 is to provide dynamic updates when users log in and out of the network. However, due to a slew of bugs, UTLite is quite broken. Most of these bugs will be fixed in CM 5.0.3 which is due out tomorrow. There will be one outstanding bug that will affect workstations with multiple interfaces. This will not be fixed until CM 5.0.4.
In order to take advantage of all of the bug fixes, you will have to re-deploy the UTLite33.exe executable to all workstations.
There will be a few application updates for new device support. Campus will be updated to 5.0.3 and DFM to 3.0.3. These updates can be downloaded from the LMS Software Center under Common Services > Software Center > Software Update. The new RME device packages can be downloaded under Common Services > Software Center > Device Update.
I wrote all of the code for the bug fixes in 5.0.3, so I know those problems are fixed. The only open problem in 5.0.3 relates to end hosts with multiple NICs. Those may cause UT to report incorrect information.
The way UT works with UTLite is first an end host entry must be added to UT. This is typically done by a UT acquisition, but it could also occur if dynamic UT is being used. Once the entry is added to the UT database, then the next UTLite update to come in from that host will be written to the database by the UTLITE daemon. The UTLITE daemon then caches this entry for 24 hours. No new identical updates will be processed until that cache expires.
What you might be observing is that end hosts are coming on line before UT has acquired their entries. They send an update to UTLITE, and UTLITE caches the entry. Then, when UT acquisition runs, the entry gets added with no username information. The next UTLite update from the end host is ignored since it is cached.
You can check if this is the case by restarting the UTLITE daemon, then running reports over time to see if users start to come into UT. DO NOT run any new acquisitions while this is happening. By default, UTLite will send updates every 10 minutes.
I have just filed a new bug against UTLite in 5.0: CSCsq08600:
User Tracking does not show usernames from Windows end hosts.
This can occur if the end user connected their computer to the network prior to that entry being acquired by User Tracking. As a result, their username update will be ignored.
Restart the UTLITE daemon on the CiscoWorks server after the end host entry appears in the User Tracking end hosts report:
Then wait up to 10 minutes for a new username update to be sent by the end host to User Tracking.
Note: NMSROOT is the path into which CiscoWorks was installed. By default, this is /opt/CSCOpx on Solaris and C:\PROGRA~1\CSCOpx on Windows.
I have a feeling this may be the bug you're seeing. However, since you have opened a TAC service request, I sent your engineer instructions on testing for this bug in addition to other troubleshooting steps.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...