DFM - device_selector.jsp!!!null

[bowser]

Hi,

I seem to have a recurring fault with DFM when opening Device selector. This time I temporarily disabled DCR syncing from the selector page, rediscovered two troublesome devices, then tried to open device selector page again to receive:

Problem with File /WEB-INF/screens/dcrAdapter/device_selector.jsp!!!null

This is the third time I have had this problem. Usually I then need to re-register DFM with script

(CALL %NMSROOT%\bin\pdreg.cmd -r NOSServer)

This trashes my DFM config though. Is there a way to resolve fault without losing DFM settings?

thx

[Joe Clarke]

This should not be required. There was a bug in DFM 2.0.3 where NOSServer was improperly registered on Windows. However, this has been fixed in DFM 2.0.4. As for the JSP error, these types of problems can be caused by a number of things. If you run:

logview NMSROOT\MDC\tomcat\logs\stdout.log

Then reproduce the problem, you should see an exception or some other error spit out on the command prompt. This could be helpful in determining a cause. In any event, if you have not already done so, I would upgrade to DFM 2.0.5.

[bowser]

Thanks for the advice.

I upgraded to DFM ver 2.0.5. The error message still persists. stdout.log records:

action: Processing a GET for /AFDAction

[Thu Jul 13 13:15:06 CST 2006] Context:/dfm SessionID:5FB31C7CCEBCCCE6C55185CCB6C77BA2 CoreID:33513CC8BC8EA885F077BC779C4CFD58

[Thu Jul 13 13:15:06 CST 2006] CoreContextNexus ValidateConnection:true

[Thu Jul 13 13:15:06 CST 2006] Invoke doLicenseCheck!

[Thu Jul 13 13:15:06 CST 2006] DoLicenseCheck Returned:true

action: Looking for Action instance for class com.cisco.nm.trx.afd.Action.AFDAction

PMUtil - in getActivePartition

PMUtil - non-msp build - return 0

PMUtil - in getActivePartition

PMUtil - non-msp build - return 0

13/Jul/2006 13:15:06:873 ERROR Ajp13Processor[9009][3] com.cisco.nm.xms.ogs.client.OGSClientProperties getInteger - Cannot get value for property. Using default.

I search Cisco.com bug toolkit as well as the forums. Any ideas?

[Joe Clarke]

It looks like you went to AAD rather than Device Selector this time. Are you saying that you see a similar JSP error when launching AAD?

The error at the end makes me think there may be a problem with DFMOGSServer. However, more troubleshooting needs to be done. At this point, it might be best to open a TAC Service Request so that additional logs, screenshots, and a more complete problem description can be collected.

[Joe Clarke]

I forgot to mention that if you wanted to try something safe and quick to see if it resolves the JSP problem, shutdown crmdmgtd, then delete everything in NMSROOT\MDC\tomcat\work\standalone\localhost . Then restart crmdmgtd. This will clear out the JSP cache, and force all JSPs to be recompiled the next time they are called. If any JSP had a bad timestamp, its cache entry might not have been updated, and this CAN lead to the JSP errors you were seeing.

I'm not saying this will definitely fix your problem, but it it is quick and safe to try. If you still see these errors, a Service Request would be the way to go.

[bowser]

Thanks for your advice Joe.

I think that we have worked out what is causing the issue. Our LMS uses ACS for authentication, along with all our network equipment. When I run the 'Devices not in ACS report', I have approx 12 switches that were removed from the network 6 months ago listed. I have exported DCR, DFM, RME & CM devices in an attempt to find were they are hiding in LMS. I cannot find them anywhere.

TAC have informed me these devices are why the error is being generated. How can I remove them?

[Joe Clarke · Accepted solution]

The devices have to be in DCR for them to show up in that report. However, they not showing up in the export because they are not authorized in ACS. To remove them, you have three choices. One is to reinitialize the CMF database. This is a bad choice as it will remove all devices from all LMS applications.

The second choice is to temporarily disable ACS integration, remove the devices, then re-enable it. The only downside to this is it will require two dmgtd restarts.

The third choice is to temporarily add theses back to ACS, remove them from DCR, then remove them from ACS.

[bowser]

Thanks Joe, I used the second step and the fault is resolved. Much appreciated.