| You should have a log entry in the Application Event Log on the server
indicating a
reason for the failed downloads, but basically there have been four
scenarios causing this problem: (1) Quotas are enabled on the WSUS server and the SYSTEM account has
not been excluded from the quotas.
(2) When storing content on a non-system drive, the .NET Framework v1.1
installation fails to give READ permissions to the NT AUTHORITY\Network
Service account. This primarily occurs on Windows Server 2003 systems where
there is a Network Service account. On Windows 2000 systems, the Local System
account already has Full Control to all logical volumes, and that's the
context in which WSUS operates, so I this is normally not an issue
on Windows 2000 servers.
(3) The proxy/firewall between the WSUS server and microsoft.com doesn't
fully support the HTTP v1.1 protocol, specifically the Range Header Protocol
which is required for BITS to function in background mode. This has been
observed on SonicWall firewalls, Raptor (Symantec Enterprise v6.5), and, in
general, on any firewall appliance or software released prior to the HTTP
v1.1 specification (1999). For the newer SonicWall boxes, there is an
Advanced configuration option that will enable this feature, see the thread
in the newsgroup - a search on keywords "WSUS" and "SonicWall" should turn
that thread up -- which provides explicit details on configuring a newer
SonicWall box.,
(4) The fourth scenario involves how a proxy is configured, or capable, of
supporting simultaneous HTTP (80) and HTTPS (443) connections from the same
client, as well as how the WSUS server has been configured to use the proxy
server. We've seen several scenarios where, apparently, the proxy was not
able to "switch" the client from the HTTPS session (to do synchronization)
to the HTTP (80) session to do file downloads. I'm not a proxy configuration
expert, but I do understand the theory and purposes of a proxy server, so my
comments should be taken in that context.
By default, the WSUS Admin console presents a configuration for a single
proxy port. If the proxy server supports multiple proxy channels by protocol
or application proxy, the WSUS server can be configured through IE settings
and the 'proxycfg -u' command to route the requests to specific inbound
ports on the proxy server.
If the proxy server can only listen on one port for all requests, the
proxy needs to be able to dynamically switch between protocols from the same
client -- since it's possible that the WSUS server could be doing a
synchronization concurrently with BITS downloading content (especially if
BITS is downloading Gigabytes of content over a many-hour period of time).
IMO, the best "solution" for Scenarios #3 or #4 is to bypass the proxy
server entirely; however, I understand that for organizational policy
reasons, and sometimes for technical reasons (e.g. the firewall /is/ the
proxy server), that's not always possible.
A workaround for Scenario #3 is to place BITS into foreground mode, using
the WSUS Server Diagnostic Tool, but that has implications of its own for
network and server performance, so it should be considered carefully as a
long-term solution. |
