There are also /known/ issues with the SonicWall products and the BITS
technology that downloads updates.
BITS uses HTTP v1.1, specifically the Range Protocol Header. Apparently by
default, the SonicWall products do not support the Range Protocol Header. This
is tied in with the AV scanner, and something else. On the newer products,
there is a config option buried down in the Advanced configs for the AV
scanner (iirc), that will permit you to enable Range Protocol Headers.
Here's the relevant excerpt from the last time I posted info about this in the
WSUS newsgroups:
Originally posted by Marc Meltzer, on 8/16/05, in the thread "WSUS and
Sonicwall"
|"Marc Meltzer" <themeltz@nospam.postalias> wrote in message
|news:ecqPfApoFHA.1372@TK2MSFTNGP10.phx.gbl...
[***]
|> You must enable a hidden option to allow Range requests when you have the
|> Gateway Antivirus service installed:
|>
|> When you log into the Sonicwall appliance, you will be at the "main.html"
|> page. Change this to "diag.html". You will see a warning. Click on
|> "Internal Settings" on the upper left. The third to last checkbox option
|> is
|> "Enable HTTP Byte-Range requests with Gateway AV".
[***]
"John Griffith" <JohnGriffith@discussions.microsoft.com> wrote in message
news:67A88FF0-E052-4A22-9333-53976F93BD6A@microsoft.com...
> This is VERY useful information. We don't have a proxy server, nor do we
> have
> any proxy server settings enabled in IE. We use a SonicWall with adress
> translation. Direct access is what the result is when I use the tool as you
> directed. I still get the same behavior as before. Anything else I can try?
>
> "Lawrence Garvin [MVP]" wrote:
>
>> 0x80190193 is an HTTP '403' error, and is almost always caused by a
>> firewall
>> or proxy server blocking access.
>>
>> However, it should also be noted that the Windows Update Agent uses
>> WinHTTP,
>> and this protocol must also have proxy configurations set up. Most likely
>> you've configured the proxy server for Internet Explorer, but not for
>> WinHTTP.
>>
>> Turning off the port blocking is confirmation of this, as then WinHTTP has
>> full access to the other side.
>>
>> Running the Client Diagnostic Tool on this client would confirm that, in
>> the
>> proxy configuration report section.
>>
>> To duplicate the correct IE proxy settings to WinHTTP, execute the command
>> 'proxycfg -u' at each client.
>>
>>
>> "John Griffith" <John Griffith@discussions.microsoft.com> wrote in message
>> news:A0BAE5BC-EC79-4CC0-BD15-C1199434AB9D@microsoft.com...
>> > Both those ports are open, and secure web forms and regular web browsing
>> > work. The error number is 0x80190193, and when I turn off all port
>> > blocking
>> > it starts working. Is there another port or portocol that isn't obvious?
>> > This
>> > started only recently, within the last couple of months.
>> >
>> > "MowGreen [MVP]" wrote:
>> >
>> >> John,
>> >>
>> >> Ports 80 and 443 need to be open.
>> >>
>> >> MowGreen [MVP 2003-2006]
>> >> ===============
>> >> *-343-* FDNY
>> >> Never Forgotten
>> >> ===============
>> >>
>> >> John Griffith wrote:
>> >>
>> >> > I need to know what TCP port to open (outgoing) in my firewall to
>> >> > support
>> >> > Windows Update. When I use the gateway address the router that's wide
>> >> > open to
>> >> > the Internet, live updateworks well, but through our firewall, does
>> >> > not.
>> >> > Which ports do I open?
>> >>
>>
>>
>>