cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
581
Views
4
Helpful
1
Replies

CDR access is prompting for logon.jsp download

miked
Level 1
Level 1

call manager 3.3.3sr4a, OS 2.7 sr2. Whenver client attempts to start CDR irt prompts for a Open. save, cancel or more info for the logon.jsp file. This occurs no matter where you try run the CDR from. i tried over VPN using browser on my PC and get the same prompt.

cdr version was reinstalled twice to no avail. TAC is baffled.

1 Reply 1

jasyoung
Level 7
Level 7

I'm having a hard time thinking why that would happen myself. Troubleshooting this one will be fun, as I'm sure you've already found out with TAC.

Find a telnet program that can log its output, such as SecureCRT and let's confirm what's coming out of IIS/Tomcat. Connect to your CallManager on port 80 and start logging your session. There'll be no banner, just a cursor sitting there. Type in the following:

GET /art/Logon.jsp HTTP/1.1

Host: yourcallmanagersname

[hit enter on a blank line]

There should be quite a bit of output. Take the log and attach it to a post in this thread so we can look at it. We want to make sure the HTTP headers and HTML file itself (in the META http-equiv tags) specify the right MIME type, which would be "text/html".

Browsers use MIME types as an indicator of what kind of object is being downloaded. For instance, you would see a mime type of "application/octet-stream" if you were downloading an executable like a plugin from CCMAdmin. The browser has a list of actions it takes for various MIME types. For "application/octet-stream" it would usually prompt you to save the file. For others such as media files, it might launch a player. Internet Explorer sometimes wants to be smart and override the MIME type based on the file name or even the content, but that shouldn't happen here.

While you're at it, let IE go ahead and download what it thinks is Logon.jsp and attach that to your post as well. It should be the same object you get sent via your telnet session, but let's just make sure IE isn't mangling it somehow. Of course, since you're having this unexplained problem, it's hard to guarantee you're getting the right HTML document at all. That will be one of the things we find out from the logs and files we collect. A screenshot of the info that comes up when you hit "More Info" at the Save dialog would also be instructive.

With these things we'll have a better idea of what the webserver itself is returning and a copy of the hints that tell IE what to do with it. If they look good, you might have something odd with your browser(s), but if you've tried from several clients that's probably not the case.