Bug-fixes after LMS 3.2 upgrade

Unanswered Question
Dec 16th, 2009

I'm soliciting input on any additional updates/patches to apply after upgrading to LMS 3.2. The following quartet are the only ones I find so far:





The first two might even be available via Software Update on LMS 3.2. If so, would I be better of letting Software Update handle their installation, instead of doing it myself on CLI?

Are there addtional bug fixes (either publicly downloadable or request-from-TAC) than the two above that might be beneficial on Solaris 10, given only the following components will be installed?

1.  CiscoWorks Common Services
2.  LMS Portal
3.  CiscoWorks Assistant
4.  CiscoView
5.  Resource Manager Essentials
6.  Campus Manager
7.  Internetwork Performance Monitor

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
yjdabear Wed, 12/16/2009 - 12:00

Thanks! I take it the SPs aren't installed by Software Update then (CLI install required)?

Are there any interdependencies between these SPs and patches, in other words, any particular recommended order of installation?

Joe Clarke Wed, 12/16/2009 - 12:06

These service packs are installed like any other.  You do them from the command line on the server using setup.sh.  You should first install them both, then update all available device packages for RME, Campus, and Common Services, then apply the patches.

Marvin Rhoads Wed, 12/16/2009 - 15:12

I can't say whether this applies to a Solaris installation, but my recent experience in applying package updates on a Windows installation was that the GUI did not end up bringing the Ciscoworks server processes back up completely. I even waited as long as an hour+. An OS-level restart (reboot) was necessary. On the other hand, when I executed the CLI package update, it did gracefully stop and restart Ciscoworks independent of the underlying Windows Server 2008 OS.

Additionally, having to manually restart after an installation did not gracefully bring CW back up appeared to result in the package installation not being logged properly as being completed. As a result, subsequent device updates with the package as a dependency would not install. I had to back out the package (MDF in this case), reinstall from the CLI and then add the dependent package updates, also from the CLI.

As Joe noted, the component updates (RME, CM, etc.) need to be done from outside the CiscoWorks application (setup.sh in Solaris and running the self-extracting executables in Windows).

yjdabear Thu, 12/17/2009 - 08:25

Thanks for sharing your experience. The thread over LMS' Mdf version confusion is still rather fresh in my memory. It's good to hear there's actually a workaround to it. It appears

the combo of Solaris 10 and LMS 3.1 fares better than Windows in that regard, though I did just find that

a couple of the *OGS* processes didn't come back from the GUI-driven Device Pkg

updates, requiring a full-blown "dmgtd" restart. The aftermath is now

"pdshow" reports even more no-longer-existent

Proc IDs than ever before.

Joe Clarke Thu, 12/17/2009 - 07:04

It is improper for you to post executable code for LMS to this forum.  Such action is forbidden by the copyright.  Please delete this file.

My guess is the bug in question is CSCtc36355.  I did produce a patch for this bug which is properly obtained through TAC.

Michel Hegeraat Thu, 12/17/2009 - 02:28

If you use radius authentication you need another patch.

I got a working version for of RadiusLoginClient.class LMS 2.6 once.

I found that the same old RadiusLoginClient.class was still comming with LMS 3.2 and was causing the same issue so I replaced it with the attached one, resolving the issue.

I can't find the bugid anymore, don't believe it is visible anyway.



Message was edited by: Dan Bruhn Removed attachement

yjdabear Thu, 12/17/2009 - 08:32

Thanks for the heads-up on the RADIUS bug. Cisco Secure ACS is the AAA backend here, and luckily it's for authentication with LMS only.


This Discussion