RME config archive problem - lms 3.2

[cmarva]

just wondering if anyone else has seen this.

about a month or so ago, I grabbed about 6 or 7 patches for our ciscoworks machine, across cm, rme, and cs. (yeah, we were a little behind)

after applying these patches, it seems, all of the 2960s and 4948s are failing the config archive with the following:

cm00139: could not archive config:cause: action: verify that device is managed and credentials are correct. Increase timeout

value if required.

so I've triple checked the credential set applied to these devices, adjusted timeout and retry values, and have gotten nowhere.

Deleting these devices doesn't seem to help, they are rediscovered just fine, but the config archive continues to fail.

Other than maybe trying to reinstall the rme patches (or uninstall) that were recently applied, I'm out of ideas. This is LMS 3.2.1 with

cm 5.2.2

cs 3.3.1

rme 4.3.2

running on windows server 08.

So if anyone may have seen this and/or has any advice, I'd appreciate it. Thanks - chris

[Joe Clarke]

You need to enable ArchiveMgmt Service debugging and then reproduce the fetch failure for one of the affected devices.  Debugging can be enabled under RME > Admin > System Preferences > Application Loglevel Settings.  Once the job has failed, post the dcmaservice.log.

[cmarva]

Joe,

I already had enabled debug level on the two archive settings. I searched all through the dcmaservice logfile for both ip and

sysname of a couple affected devices, and nothing showed up. I went back and enabled debug level for all, and once again

searched the dcmaservice logfile (since they're pretty big, I was going to try and just snip out the relevant portions) and am not seeing anything at all for the affected devices.

What I can do is, tomorrow, snip out everything for the run that will happen tonight. That should give a smaller file that should contain everything relevant.

Thanks for the help, I appreciate it - chris

[Joe Clarke]

You should be triggering an update for one device only under RME > Config Mgmt > Sync Archive.  If nothing is updated in the log then, you may have a thread lock.  In which case, you will need to bounce ConfigMgmtServer with the commands:

pdterm ConfigMgmtServer

pdexec ConfigMgmtServer

If that causes your config archive to work, then you will need to upgrade to LMS 3.2.1 (downloadable from Cisco.com) to get some needed bug fixes.

[a10519dlw]

I am having the same problem.

This where I am version wise:

LMS 3.2.1

Campus Manager  5.2.2
Ciscoview  6.1.9
Ciscoworks Assistant 1.2.0
Common Services  3.3.1
DFM   3.2.1
Intergration Utility 1.9.0
IPM   4.2.1
RME   4.3.2
LMS Portal  1.2.1

Dave

[cmarva]

this kinda went to the back burner since it wasn't really a showstopper. Interesting thing, though. We are beginning to eval

IOS 15 on a number of platforms, and the 2960 is one of them. We upgraded last week and now the config does seem to

be archiving ok. I think this will work itself out during our upgrade cycles. If I get a chance, I'll dig more into this - chris

[cmarva]

ok, so it's been a year and a half since last post. So in addition to the above mentioned archive failures with the 4948s, the 4948s were also showing up in config out of sync summary. The only difference that were showing between running and startup was the ntp clock period.

I did see that the clock period statement was in the exclude list for routers and a bunch of other things, but not for the 4948s. I added this as an exclusion yesterday. Today when I checked, all 4948s are archiving now, and are off the out of sync report. Never would have crossed my mind to check there, but that exclusion seems to have done the trick. Maybe someone else can use this if they're seeing the same thing. - chris