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
I ran a live logging session on ISA against a "problem" client, and saw some interesting results - a large amount of "Failed Connection Attempt" entries, like this:
Failed Connection Attempt <ISA Server name> 02/10/2008 18:10:43
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...?
Much appreciated...
< Message edited by Hapexamendios -- 3.Oct.2008 8:06:01 AM >
Did you add all the below sites to URLs to Windows Update URL set as documented in KB885819. The policy to fetch the updates from Windows Update is part of System Policy.
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>
<FRUSTRATION!!!>
< Message edited by Hapexamendios -- 8.Oct.2008 11:23:24 AM >
I think you mentioned that there was a device that was handling traffic in addition to the ISA firewall, is that right? Is that device behind of, along side, or in front of the firewall?
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.
Has anyone else experienced or found a solution to this problem? I have encountered much the same issue.
Windows update works fine via our firewalls but for MSBITS clients via the ISA servers it fails
All of the anon access sites have been added (the fact I have to make exceptions to an authenticated internet policy for the sake of MS is annoying but a separate matter).
MSBITS now dowloads .cab's and .exe's but always fails on .psf files
Recently, in order to get updates onto the ISA servers themselves I had to stop the ISA services at which point the .psf files downloaded successfully.
Has anyone else experienced or found a solution to this problem? I have encountered much the same issue.
Windows update works fine via our firewalls but for MSBITS clients via the ISA servers it fails
All of the anon access sites have been added (the fact I have to make exceptions to an authenticated internet policy for the sake of MS is annoying but a separate matter).
MSBITS now dowloads .cab's and .exe's but always fails on .psf files
Recently, in order to get updates onto the ISA servers themselves I had to stop the ISA services at which point the .psf files downloaded successfully.
If the URL of the failed download is then copied & pasted from these logs into IE on the same host, it hits the same access rule but this time the download is successful:
that was already set in IE, tried turning it off but no change - not sure if this should be configured elsewhere to affect MSBITS?
The only obvious difference I can see when comparing the logs is that the MSBITS filterinfo has stats for "range" which dont appear when the request is generated by IE - any significance there?
that was already set in IE, tried turning it off but no change - not sure if this should be configured elsewhere to affect MSBITS?
The only obvious difference I can see when comparing the logs is that the MSBITS filterinfo has stats for "range" which dont appear when the request is generated by IE - any significance there?