My first post on this forum; though it has helped me a great deal in the past :)
Here's my problem:
Recently, I've noticed that, when attempting to perform Windows or Microsoft Update through our ISA 2006 Std server, some (but not all) of the updates are failing. I ahev a Firewall rule which is designed to allow anonymous access to all the Windows Update sites as highlighted in
Client agent: Microsoft BITS/6.7 Object source: Upstream (Object was returned from an upstream proxy cache.) Cache info: 0x8800040 (Request includes the RANGE header. Response includes the LAST-MODIFIED header. Response includes the VIA header.) Processing time: 31 ms MIME type: -
I'm struggling to find a relevant common denominator; and I'm unsure I have, but it seems that these "Failed Connection Attempt" have this in common:
they originate from the MSBITS/6.6 or MSBITS/6.7 client on the machine instead of the WIndows Update Agent or the browser
they are all attempts to download ".psf" files
Having checked further, there are entries for successful connections by MSBITS/x, but only when ".exe" files are the target as selected by the Windows Update site.
The last piece of obviously relevant information is that ISA connects through a content-filtering server - MIMESweeper for Web by Clearswift, which is the "<content-filtering server>" above. It's been checked over, and if I use it as the proxy instead of the ISA serevr, there's not a single hitch.
Can anyone there assist with a method of troubleshooting this? I've been through everything from the Networks, System Firewall policy and my own firewall rules - however as it's the "MS Updates" rule I created being registered as the blocking rule, surely it's somewhere there...?
< Message edited by Hapexamendios -- 3.Oct.2008 8:06:01 AM >
Yes; though I don't see a System firewall rule for that in ISA 2006. Mines is a custom rule, created as outlined in kb885819 (in the "More Information" section, though I'm disturbed by the fact that ISA 2006 isn't mentioned in the article. It contains all those sites in a URL set, it allows "All protocols" and "All content types".
Also, my issue isn't identical to the kb article Scenarios - the issue for me arises at the "Downloading updates" phase, having successfully scanned for, selected and clicked to "Install Updates". The downloads all fail, and I see "0x80244019" in the update history for the client.
I am thinking it's these .psf extensions, which I think are for the Packager for Windows handler (can't remember the handler's name, no time to look it up!) Since my rule doesn't dicriminate by content type, I can't understand why this would be the case, but it seems so.
Any more ideas - or anyone else have any advice as to how to troubleshoot this issue further?
I'm not sure what you mean there; however it sounds close to one fo the tests I performed: I edited the "Internal" network's properties, and on the "Web Browser" tab, I set the domains cited in kb885819 in the Direct Access field there.
However, we don't use the automatic configuration script to set browser settings; we use Group Policy, with a GPO attached to each AD site.
I've just tested it again; I have the Firewall Client running on my machine, so clicking the "Configure Now" button on the Web Browser tab sets IE to use the auto-configuration script
How would I check that all the pre-requisites for using the method above have been met? For example, if the auto-config script is needed, how to check that the script exists and is configured correctly; does the type of network template involved have an impact (this box is uni-homed).
<Annoyingly, my superior insists that this "feature" of double and triple posting is caused by the site - i.e. he's blaming your site in this case; however, I'm sure it's another sign of complete mis-configuration of the proxy I'm trying to fix, which I built, copying from his original build verbatum>
< Message edited by Hapexamendios -- 8.Oct.2008 11:23:24 AM >
Yes, we have a server running Clearswift's MIMESweeper for Web.
This is the Internet-facing device, with ISA connecting through it to the web.
Its purpose is really content-filtering. Haven't found anything on their forums indicating a known issue or mis-configuration.
I've confirmed it's not that - at least, I can browse the web directly through it with no issues (using it as my browser's proxy), so none of its "scenarios" are directly responsible for stopping the traffic. It could still be that the issue is for ISA downloading certain copntent types through it, although that doesn't really make sense if I can browse through it.
The true test is not to bypass the ISA firewall, but to bypass the device in front of the ISA firewall. It could be that the device in front of the firewall is returning non-RFC responses, and so the ISA firewall is dropping the connections.