LMS 3.0 Campus User Tracking

Unanswered Question
Mar 5th, 2008

Having problems with the usernames tracking in the Windows 2003 AD environment, only small portion (10%) of all usernames is visible in the report and even this is not consistent. Apparently the UTLite33.exe file is bigger in LMS 3.0 than it was in LMS 2.6 (the name is the same,though). So far the only difference I noticed between them is that the old one sends the info about all the NICs (connected and not connected) on the user's PC with the same IP for all the NICs, even the ones that do not have any IP assigned; the new one sends the IP only for the NIC that has IP (for the other NIC it send NULL), however it confuses the MAC addresses (takes the MAC from the not connected NIC), all visible via the wireshark traces.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Joe Clarke Wed, 03/05/2008 - 13:27

First, your swapped MAC problem sounds like a new bug. Unfortunately, I don't have any multi-homed Windows machines with which to test. You should consider opening a TAC service request to have that looked at.

As for the missing updates problem, what version of Campus Manager is this? Please provide a screenshot of the end host properties for one end host which is missing a username (i.e. click on the MAC address in the end hosts report, and snap the resulting pop-up).

Something else you might want to try is to restart the UTLITE daemon on the server, then send some new updates from end hosts with missing records, and see if UT updates.

dmitry Wed, 03/05/2008 - 16:35

Attached is a PDF with the screenshots of the ipconfig /all, the pop-up after clicking on discovered MAC and the output of the wireshark that captured the execution of the UTLite33.txt from CM ver 5.0.2 / U/H tracking ver 2.0.2

I actually reinit the UT DB and took the snapshots after.


Joe Clarke Wed, 03/05/2008 - 17:03

It looks like you're hitting CSCsl97497 which accounts for the (null). I see how the IP/MAC info can get screwed up, too. This should be fixed in CM 5.0.3.

As for the updates not being processed, go to User Tracking > Admin > Debugging Options > Dynamic User Tracking, and enable TRACE for all "UT Lite" components. Send some updates to the server, then post the utlite.log.

dmitry Thu, 03/06/2008 - 08:33

Enabled the debug but do not really see much happening in utlite.log (attached). Tried to reboot the user's PC, so the UTLite33.exe / UTLiteNT.bat get executed by the login policies, also tried manually in CLI with LMS parameters, nothing shows up in the log.


Joe Clarke Sat, 03/08/2008 - 07:59

As I said, you need to set the level to TRACE for the useful messages to get logged.

dmitry Mon, 03/10/2008 - 16:29

Missed the TRACE option the first time, OK, here is the output for my PC:

2008/03/10 19:23:04 Thread-8 utlite TRACE SocketListener: Data received from IPAddress: ,Packet Data: 757365724e616d653d64676f6e63686172656e6b6f406f746e2e6c6f63616c7c6d6163416464726573733

2008/03/10 19:23:04 pool-1-thread-1 utlite TRACE UtliteDecoder: UserName: [email protected] ,MacAddress: 00:16:CF:14:5D:0B, IPAddress:

2008/03/10 19:23:04 pool-1-thread-1 utlite TRACE PostUtliteDecode: Rejecting UTLITE event since,user data received are same,MacAddress: 00:16:CF:14:5D:0B

This MAC belongs to the wireless adapter which is not active and does not have an IP assigned.

The same reject is happening to all the users in the log


Joe Clarke Mon, 03/10/2008 - 19:28

This means that UTLITE has already received an update for this MAC, and is not reprocessing the update. I have filed a new bug, CSCso14144, which may explain some of your problems. The other (this wireless thing) is part CSCso09676 and part CSCsl97497. Neither of these two bugs have a fix available yet (CM 5.0.3 due out this summer).

The former bug, CSCso14144, does have a fix, and you can open a TAC service request, and have your engineer contact me to get it.

maismail Sat, 03/08/2008 - 00:32

We are having the same issue here even with the latest version of CM

I hope there is a solution from Cisco



This Discussion