cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1930
Views
0
Helpful
21
Replies

Campus manager & DCR

philmcgregor
Level 1
Level 1

The automation between CM and DCR appears to have stopped working on our CiscoWorks.

Changes made to the DCR are not reflected in the device list in CM, and new devices discovered by CM are not being added to DCR.

Where do i check the settings to ensure the two modules are interacting properly?

21 Replies 21

3/3

These files all turned out to be binary. Please just compress the whole log, and post it. It's just plain text, so it should compress down quite well.

Oh, right. Why didnt i think of that...

Looks like there is a problem with DCR. It's strange, though, that Discovery can read from DCR, it just cannot write to it. To figure out what is going on will require DCR debugging. Since that is not so straight-forward in LMS 2.6, I recommend you open a TAC service request, include this discovery.log, and they can instruct you on how to enable and then disable DCR debugging.

Ok, thanks alot jclarke.

Interesting...

On a hunch i went back and reinstalled our test implementation.

Discovery and DCR are working perfectly now.

Only difference to this configuration and the ones tested previously was we did not change nameserver.updateDCRDisplayName to true, as was suggested to combat our earlier problem: (http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Network%20Infrastructure&topic=Network%20Management&CommCmd=MB%3Fcmd%3Ddisplay_location%26location%3D.1dde9a36)

Our current issues seemed to start around the time we made this change.

Any ideas why updateDCRDisplayName would play such havoc on DCR?

It wouldn't. This property just tells Campus to send a little bit more information to DCR when it does its update. It would not have caused the CSTM error you were seeing.