locked
Content file download failed. RRS feed

  • Question

  • I haven't been able to find anything on this anywhere. Trying to get Windows 8.1 Update (KB2919355) to download, but it keeps failing.  I'm using WSUS 3.2 on Server 2008 R2, 156GB free space on E drive.

    This error has been occurring since April, but all other updates are downloading fine.  If I sort by file status, only the 3 updates for 8.1, 8.1 x64, and 2012 R2 are stuck trying to download.

    Anyone have any ideas?

    Event ID 364:

    Content file download failed. Reason: An attempt was made to move the file pointer before the beginning of the file.

    Source File: /msdownload/update/software/crup/2014/02/windows8.1-kb2919355-x64_66955196a82751d1c8d9806d321487562b159f41.psf Destination File: E:\WSUS\WsusContent\41\66955196A82751D1C8D9806D321487562B159F41.psf.

    Thursday, September 18, 2014 8:05 PM

Answers

  • so I chose express installation files to reduce update times during deployment.

    It won't do this.

    Express Installation Files (which really are an almost pointless mechanism given the abandonment of service packs) are designed so that you can transfer much smaller deltas of very large update files across a WAN connection instead of having to transfer the entire update. Generally the only place any such capability exists is with service packs; regular updates don't actually use Express Installation Files (but they do still define a PSF file so the WUA knows there is NO capability to use Express Installation Files).

    About the only thing using EIF gets you these days is downloading tens of gigabytes of legacy service pack content to the WSUS server and unnecessarily consuming Internet bandwidth and disk storage. As for the legacy service packs, they all should already be 100% deployed, or slipstreamed into your MDT images (e.g. SP1 for Win7/WS2008R2).


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    • Marked as answer by Jay Lay Wednesday, September 24, 2014 4:58 PM
    Sunday, September 21, 2014 3:01 AM
  • Event ID 364:

    Content file download failed. Reason: An attempt was made to move the file pointer before the beginning of the file.

    You're correct that this error has never seen before.. well, at least not in my tenure in this forum. ;-)

    My guess would be that anti-virus software is interfering. Ensure that the ~\WSUSContent folder tree is excluded from any Scan-On-Create functionality of your AV/AM software, and then try again.

    Although I'm also curious as to why you're downloading a PSF file.... that suggests that you have enabled Express Installation Files -- probably not something you really wanted to do.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Friday, September 19, 2014 2:05 AM
  • Alright, disabling EIF solved event ID 364 errors.  KB2919355 is now visible to 8.1 and 2012 R2 clients. The updates are baking into my base WIM files now. Thanks for helping me figure this out Lawrence!  Next stop, imaging Surface Pro 3!
    • Marked as answer by Jay Lay Wednesday, September 24, 2014 4:58 PM
    Wednesday, September 24, 2014 4:57 PM

All replies

  • Event ID 364:

    Content file download failed. Reason: An attempt was made to move the file pointer before the beginning of the file.

    You're correct that this error has never seen before.. well, at least not in my tenure in this forum. ;-)

    My guess would be that anti-virus software is interfering. Ensure that the ~\WSUSContent folder tree is excluded from any Scan-On-Create functionality of your AV/AM software, and then try again.

    Although I'm also curious as to why you're downloading a PSF file.... that suggests that you have enabled Express Installation Files -- probably not something you really wanted to do.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Friday, September 19, 2014 2:05 AM
  • There are no warnings or notifications from Symantec Endpoint Protection, but I have now fully excluded the WSUS folder from any type of scan or active protection.  I clicked retry download in WSUS and will see what happens.

    I did enable express installation files intentionally.  We have a 1Gbps fiber line so bandwidth isn't an issue, and I'm only using 344GB of storage currently.  We use WSUS as part of our MDT deployments so that machines are as up-to-date as possible once deployed, so I chose express installation files to reduce update times during deployment.

    Friday, September 19, 2014 4:15 PM
  • so I chose express installation files to reduce update times during deployment.

    It won't do this.

    Express Installation Files (which really are an almost pointless mechanism given the abandonment of service packs) are designed so that you can transfer much smaller deltas of very large update files across a WAN connection instead of having to transfer the entire update. Generally the only place any such capability exists is with service packs; regular updates don't actually use Express Installation Files (but they do still define a PSF file so the WUA knows there is NO capability to use Express Installation Files).

    About the only thing using EIF gets you these days is downloading tens of gigabytes of legacy service pack content to the WSUS server and unnecessarily consuming Internet bandwidth and disk storage. As for the legacy service packs, they all should already be 100% deployed, or slipstreamed into your MDT images (e.g. SP1 for Win7/WS2008R2).


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    • Marked as answer by Jay Lay Wednesday, September 24, 2014 4:58 PM
    Sunday, September 21, 2014 3:01 AM
  • Well that's a bummer.  Still got the same error over the weekend while SEP was set to exclude WSUS folder.  I've disabled EIF, and I'm running server cleanup now.  Anyone know if this is still an issue in WSUS 3.2: http://support.microsoft.com/kb/974500/en-us ?

    Also, I do update my images every 2-3 months with updates baked in to keep deployment times short.  Just didn't realize EIF was so antiquated.

    Monday, September 22, 2014 6:23 PM
  • Anyone know if this is still an issue in WSUS 3.2: http://support.microsoft.com/kb/974500/en-us ?

    All existing WSUS v3.2 hotfixes were rolled up into KB2720211 (so they are also present in KB2734608, KB2828185 and KB2938066).

    [Edit] Ehhhh. but that's actually a WUA issue that's *not* been resolved to my knowledge. It's not really a bug, just a fact of how the WUA caches content.

    Method #2, however, should be the option of FIRST choice. DECLINE the update, and force a client detection. But note that even this methodology is designed to be a *reactive* response, only if the client freaks out.

    Then, once the client knows the update is no longer available, you can re-approve the update, and the WUA will RE-download the content that is available. (Of course.. what's also not written in that KB article is that the 'issue' only applies to updates that actually HAVE EIFs that the client can download!) :-)


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.


    Monday, September 22, 2014 10:39 PM
  • Alright, disabling EIF solved event ID 364 errors.  KB2919355 is now visible to 8.1 and 2012 R2 clients. The updates are baking into my base WIM files now. Thanks for helping me figure this out Lawrence!  Next stop, imaging Surface Pro 3!
    • Marked as answer by Jay Lay Wednesday, September 24, 2014 4:58 PM
    Wednesday, September 24, 2014 4:57 PM
  • My issue was resolve by bypassing our Proxies (TMG’s) and going straight through our Check Point Firewalls.

    It was also very strange because all the other updates downloaded fine included KB3000850 of 728mb which is 20mb bigger than KB2919355.My server was a fresh Windows 2012 R2 Virtual installation with the normal updates from the Microsoft’s update page.

    Friday, March 27, 2015 11:02 AM