LMS 2.5 on Windows 2003 Server.
Tried to update devices via Common Services > Software Centre > Device update. Selected RME and pointed to local psu_download\rme directory. The app picked up all the new device packages and I told it to install all (there were quite a lot).
After installation finished and I reconnected to LMS I was unable to view Topology Services as I kept getting an "Unable to connect to ANI server error". Tried restarting but that didn't help. In fact, couldn't even get CiscoWorks to open up! Tried the solution in topic:
which got me a little further.
Looking in the CS > Software Centre > Activity Log > Event Log there appear to have been a lot of errors installing the new packages. They all read like:
"ERROR: Error while installing (Rtr3800): Got exception during version comparision.com.cisco.nm.xms.psu.interfaces.adapter.AdapterException: C:psu_download
meRtr3800.zip cannot be installed because, CURMDFVER:1.11 is LESS THAN minReq MDFVer:1.16"
Restarted server again. Now connecting OK to LMS.
Biggest problem: Now there's nothing in my Topology Services > Network Views > VTP Views > [VTP_Domain] !! It's all blank, where there used to be over 90 devices.
Installing RME device packages has no effect on Campus Manager, so the two are unrelated. However, you most likely did not get any packages installed since you also need to update your Common Services MDF. This can be downloaded from http://www.cisco.com/cgi-bin/tablebuild.pl/cw2000-cd-one (get version 1.18), and it installed the same way as the RME device packages (except choose Common Services as the application).
As for your Campus Manager problem, exactly which version of Campus Manager do you have? The fact that you have MDF 1.11 installed makes me think it's quite old. The problem you're seeing could be an issue with DCR or with the ANI database itself. You might also check the Java Plug-in console to see if there are any errors, and make sure the devices still appear in the Campus Manager Layer 2 View as well as in Common Services > Device and Credentials > Device Management.
Have now upgraded MDF to 1.18. Re-trying the device updates for RME. Campus Manager version is 4.0.5.
Java Console had this message 88 times (yesterday):
"May 29, 2007 10:08:11 AM java.util.jar.Attributes read
WARNING: Duplicate name in Manifest: Depends-On"
I don't know if that's going to be meaningful to you or not.
Since I made the first post in this thread the LMS has performed another scheduled discovery and repopulated the device list. Unfortunatley I've still got to go and reorient my Topology map which is a bit of a pain. After discovering the missing VTP info yesterday I went into other areas of the LMS to see if the data had been removed from everywhere and it hadn't. It was still in UT, REM, DFM. I didn't get to check the Layer 2 view in CM before the information got updated - I posted the first message just before knock-off time yesterday.
Have I missed some vital instruction about what order to install updates in, or is this something I just had to learn by experience.
As usual, thanks for your help.
The Java console messages are typical, and do not indicate any problems.
As long as you download all the available updates, you typically shouldn't see a problem applying device package updates. The main caveat is to make sure you also check for Common Services MDF updates. Fortunately, the psu.log will indicate when these are required, but if you take care of the MDF at the same time as the rest of your RME and CiscoView packages, you should never see a problem.
After installing the RME updates, and some CiscoView updates as well, my Topology Services > Network Views > VTP Views > [VTP_domain] table is once again empty. Glad I hadn't already rearranged my topology map!
The Layer 2 view is still populated.
Any ideas why this has happened, or what I might be able to do to stop it from happening again in the future?
The only thing that affects VTP devices from appearing and disappearing should be Campus Data Collection. The obvious answer is that Campus detected that these devices are no longer part of the given VTP domain in its last Data Collection. That might not be the case, however. Enabling core, corex, and vlad debugging under Campus Manager > Admin > Campus Data Collection Debugging Options, then capturing the ani.log after the problem occurs might give you a better idea. Search through the log for the devices and the VTP domain in question, and see if there are any errors.
More strange behaviour now. Went to look in Device Credentials and received an error that told me to start the DCR database - which I did. Still kept getting error. Left it alone for a while and then tried again. Same error.
In the meantime, VTP View Summary table had been re-populated with devices so I started to rearrange them (on the map). When I tried to connect to Device Credentials again, nearly an hour after last attempt, still received an error.
Restarted server (physical machine - not just LMS). After restart, all devices missing from VTP View Summary table again. However, could now view Device Credentials. Had other work to do so I re-ran Campus Data Collection.
When I returned to my desk - time passed approx 40 minutes - not only was VTP View repopulated, but when I selected the "Display View" my original topo map - from before all of this drama - has come back.
If, when I start the server again in the morning, all of my devices are missing again I'll check the ani.log as you've suggested - I've enabled the debugging you described. I hope that will shed light on this very confusing issue.
This whole thing started because I couldn't get CiscoView to show me a C2960, so I tried to do a device update. Guess what? I STILL can't get CiscoView to show me a C2960! And I've torn out half of my hair trying to figure out why everything else turned to sludge in the process.
Thank God I've had some wins with CiscoWorks in the last couple of weeks - otherwise I think I'd be bald!
What version of the Java Plug-in are you using? Please provide the entire contents of the Java Plug-in console.
What error do you get trying to open the C2960 in CiscoView? What version of the Cat2960 CiscoView package do you have installed?
As you can see from the attachment: Java(TM) Plug-in: Version 1.4.2_10.
The error from CiscoView is " Message
Can't find applicable device package for 220.127.116.11. "
There doesn't appear to be a CiscoWorks package installed for Cat2960 - despite my having tried to run the Device Update tool against CiscoView about four times today so far - selecting all packages for update.
Perhaps I've been a bit distracted by the other issues that have arisen due to my trying to update the RME - but I thought the cvw folder in my psu_download directory had a Cat2960.zip file in it - but having looked again it appears not to. Re-running the updater using Cisco.com.
Updating CiscoView earlier today kept presenting me (via Event Log) with this error:
"The Package(s) Selected for Install :
Cat3560, Cat3750, Cat4000IOS, Cat6000, Cat6000IOS, CatQdm, MAR3200, miniRMON, Rtr12000, Rtr1700, Rtr2600, Rtr3700, Rtr7000, Rtr800, SwitchAddlets
Installation failed for product [CiscoView] with message : com.cisco.nm.xms.psu.packagemgmt.InstallerException: Repository in use. Another Package Support Updater client session may be modifying device support."
I tried on a number of different occasions but always with the same result.
What are the contents of NMSROOT\MDC\tomcat\webapps\CVng\WEB_INF\classes\com\cisco\nm\cvw\devpkgs and NMSROOT\www\classpath\com\cisco\nm\xms\psu\pkgs\cvw?
These look okay. You are missing the 2960 package so it's strange that PSU is not showing it to you for download. In any event, you can download it from http://www.cisco.com/cgi-bin/Software/CiscoView/cvresult.cgi?product_class=Catalyst+Switches&product=Catalyst+2960&application=CiscoView+6.1
then use PSU to install it.
PSU is still running the update via CiscoWorks that I mentioned in my last post. Perhaps it will come up with the goods this time? It seems to have been running a really long time though.
In any case I'll download the package from the link you've provided. Thanks for all your help - you certainly deserve your "Star".
PSU jobs can take a long time (10 minutes) to find all packages. However, if it goes longer than that, it may have died. The safest thing to do in that case is shutdown dmgtd, and remove NMSROOT\Psu.Lock. Then restart dmgtd, and start a new job.