The Web Server logs also appear clear and according to netmon traces the content was transferred from the Web Server to the ISA Server:
ISA Server sends the GET request to the file:
10.20.20.2 10.20.20.25 HTTP HTTP:Request, GET /mydoc.asp
Web Server answers the request with the file:
10.20.20.25 10.20.20.2 HTTP HTTP:Response, HTTP/1.1, Status Code = 200, URL: /mydoc.asp
- Http: Response, HTTP/1.1, Status Code = 200, URL: /mydoc.asp
ProtocolVersion: HTTP/1.1
StatusCode: 200, Ok
Reason: OK
Date: Fri, 20 Nov 2009 21:20:28 GMT
Server: Microsoft-IIS/6.0
XPoweredBy: ASP.NET
Cache-control: no-cache
ContentLength: 38021
+ ContentType: application/msword
Cache-control: private
HeaderEnd: CRLF
- payload: HttpContentType = application/msword
HTTPPayloadLine:
HTTPPayloadLine:
IIS Logs from the Web Server also shows that the content was correctly answered:
2009-11-20 21:20:28 W3SVC1 10.20.20.25 GET /mydoc.asp - 82 - 10.20.20.2 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+.NET+CLR+2.0.50727) 200 0 0
At this point we know that client sends the request, ISA correctly sends the request back to the web server which correctly provides the content to ISA. On the client side, Netmon just showed the encrypted conversation. In order to see what was really happening on the client side, we used HTTP Watch and there we could see that the actual content was already local as you can see in the figure below:
4. Resolution
The problem was related to the following header in the response from the web server:
10.20.20.25 10.20.20.2 HTTP HTTP:Response, HTTP/1.1, Status Code = 200, URL: /mydoc.asp
- Http: Response, HTTP/1.1, Status Code = 200, URL: /mydoc.asp
ProtocolVersion: HTTP/1.1
StatusCode: 200, Ok
Reason: OK
Date: Fri, 20 Nov 2009 21:20:28 GMT
Server: Microsoft-IIS/6.0
XPoweredBy: ASP.NET
Cache-control: no-cache
ContentLength: 38021
+ ContentType: application/msword
Cache-control: private
HeaderEnd: CRLF
- payload: HttpContentType = application/msword
HTTPPayloadLine:
HTTPPayloadLine:
Here it is the explanation why it was failing:
“In order for Internet Explorer to open documents in Office (or any out-of-process, ActiveX document server), Internet Explorer must save the file to the local cache directory and ask the associated application to load the file by using IPersistFile::Load. If the file is not stored to disk, this operation fails.
When Internet Explorer communicates with a secure Web site through SSL, Internet Explorer enforces any no-cache request. If the header or headers are present, Internet Explorer does not cache the file. Consequently, Office cannot open the file.”
From http://support.microsoft.com/kb/316431
Although this article says it applies to IE 5 and IE6, this issue happened on IE7 and IE8. This is an expected behavior and in order to fix this you will need to follow the recommendation from KB316431. The reason why it was working internally for all users is because internally the access to this web server was using HTTP and this problem just happens when using SSL. Once more ISA was not guilty , it was only doing what the web server was asking it to do.
Author
Yuri Diogenes
Sr. Security Support Escalation Engineer
Microsoft CSS Forefront Edge Team
Technical Reviewer
Mohit Kumar
Sr. Security Support Escalation Engineer
Microsoft CSS Forefront Edge Team
