Got it. Apparently, the Checkpoint firewall has settings for both the URLs the WSUS has to go and get the updates. And there is a setting that tells CheckPoint that the request is coming from the WSUS application. Once we added WSUS as an allowed application, the downloads started up again.
Dunno why it wasn't set before, and why it's been working for the year+ since we started using this CheckPoint firewall. But my updates files are flowing again. Maybe this will help someone else, in future. On Fri, Jul 17, 2015 at 10:55 AM, Michael Leone <[email protected]> wrote: > We are installing this month's Windows Updates this weekend. So Wed I > approved all that we wanted approved. I just happened to look at it > today, and there are 260 updates needing files, 10G worth. > > Event log says error 364 - Content file download failed. reason: The > server did not return the file size. The URL might point to dynamic > content. The Content-Length header is not available in the server's > HTTP reply.And lists a source and destination file. > (I see 9 log entries, going back to Wed, each with a different file name) > > Oddly, synchronization shows successful, no failures in the history. > ... Plenty of space on the download drive. > > This > https://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=.NET+Framework&ProdVer=2.0.50727&EvtID=364&EvtSrc=Windows+Server+Update+Services&LCID=1033 > > says to stop and restart BITS and the WSUSService. and re-synchronize. > Didn't help - still seeing the error in the event log. > > Ideas? I have to get the files downloaded for the scheduled downtime > this weekend. It sounds like a web server error on MS's part, but I > find that hard to believe.
