Cannot download updates in SCCM after SP1 Updrade


  • Hi all,

    I have upgraded my SCCM 2012 RTM to SP1 last week and since then I cannot download updates.

    It gives the error message "Error: Failed to download content id 16779439. Error: Access is denied

    I have tried reinstalling WSUS onto the server which seems to be working fine, but I still cannot download the updates in SCCM.

    I am a full administrator of SCCM and a domain admin on the Server itself.

    Any help would be appreciated.



    Wednesday, February 13, 2013 11:31 AM


  • Hi I am using SCCM 2012 R2, I was receiving the exact same error. I then ran the console as administrator and updates downloaded successfully.
    Tuesday, September 09, 2014 3:30 PM

All replies

  • Hi,

    It sounds like a problem with Share/file permissions in the folder that you are trying to download the updates to, I would start with checking share permissons/file permissions to the share you have selected as Software Update Package Source.

    You can check PatchDownloader.log for more details.


    -- My System Center blog -- Twitter @ccmexec

    Wednesday, February 13, 2013 12:08 PM
  • Im not sure what permissions I should be looking for, Everyone has read access to the foler, there is a Network Service account with full access, and other than that WSUS Administrators and Administrators groups have full access also.

    Here is a sample of the logs:

    Trying to connect to the root\SMS namespace on the machine.  $$<Software Updates Patch Downloader><02-13-2013 11:04:48.236+00><thread=4648 (0x1228)>
    Connected to \\\root\SMS  $$<Software Updates Patch Downloader><02-13-2013 11:04:48.237+00><thread=4648 (0x1228)>
    Trying to connect to the \\\root\sms\site_MP1 namespace on the machine.  $$<Software Updates Patch Downloader><02-13-2013 11:04:48.240+00><thread=4648 (0x1228)>
    Connected to \\\root\sms\site_MP1  $$<Software Updates Patch Downloader><02-13-2013 11:04:48.241+00><thread=4648 (0x1228)>
    Download destination = \\as024\UpdateServicesPackages\6357efc3-8d00-4981-95ba-367b12372437.1\ .  $$<Software Updates Patch Downloader><02-13-2013 11:04:48.451+00><thread=4648 (0x1228)>
    Contentsource = .  $$<Software Updates Patch Downloader><02-13-2013 11:04:48.451+00><thread=4648 (0x1228)>
    Downloading content for ContentID = 16779439,  FileName =  $$<Software Updates Patch Downloader><02-13-2013 11:04:48.459+00><thread=4648 (0x1228)>
    Failed to create directory \\as024\UpdateServicesPackages\6357efc3-8d00-4981-95ba-367b12372437.1\, error 5  $$<Software Updates Patch Downloader><02-13-2013 11:04:48.465+00><thread=4596 (0x11F4)>
    ERROR: DownloadContentFiles() failed with hr=0x80070005  $$<Software Updates Patch Downloader><02-13-2013 11:04:48.466+00><thread=4648 (0x1228)>

    I hope this is of some use.



    Monday, February 18, 2013 12:49 PM
  • First check the "UpdateServicesPackages" share permissions and ensure that the SYSTEM account has access.  For testing purposes, you could allow Everyone full control on the share - but only for testing purposes.  You are definitely seeing error 5 here, which is access denied to that path.

    Secondly, might I recommend creating subfolders within that share for your Software Update Packages, rather than pointing directly at the share.  For instance, if you are having a "Windows 7 Updates" package, then specify the path to be "\\as024\UpdateServicesPackages\Windows 7 Updates"  and this will store those specific updates within it.


    My Personal Blog:

    Monday, February 18, 2013 1:38 PM
  • Both System and Everyone were given full control to the folder, now I get no error message but it gets stuck on 0% processing indefinately.

    Monday, February 18, 2013 2:32 PM
  • I recovered the Site and it now appears to work fine.

    Thanks for the help


    Tuesday, February 19, 2013 12:24 PM
  • We are having this same issue with a new install of SCCM SP1 CU2.  All shares are setup correctly.  We found when we ran the Consoles as an Administrator everything is working.

    Kristopher Turner | Not the brightest bulb but by far not the dimmest bulb.

    Tuesday, September 10, 2013 2:02 PM
  • This is happening in our Lab as well once we installed CU2.  Both are Site servers running on Windows 2008 R2.  As soon as you start the Console in Administrator mode everything is working.  It was working fine before CU2.

    Kristopher Turner | Not the brightest bulb but by far not the dimmest bulb.

    Tuesday, September 10, 2013 2:45 PM
  • I know this is old, however, if you are selecting a deployment package and getting the error,  try creating a new deployment package and creating a new folder versus using the older one for example:  c:\share\source\windowsupdates\2014 and see if that works.  I was using windowsupdates and I would receive the same error.  When I added the 2014 it worked like a charm.



    Wednesday, January 15, 2014 4:35 PM
  • Hello,

    Please try with option - folder option on installation directory WSUS - UpdateServicesPackages folder RC - sharing - advances sharing - on permissions and add member/account from which you want to download the patches.

    Hope this will work...

    Thanks -  AnimeshShankar.


    Tuesday, February 25, 2014 6:03 AM
  • Hi I am using SCCM 2012 R2, I was receiving the exact same error. I then ran the console as administrator and updates downloaded successfully.
    Tuesday, September 09, 2014 3:30 PM
  • In my case I was trying to add updates to an existing deployment package. I found the source were that content is stored was the problem. I restarted the file server that was acting as the content source for the deployment package and the problem was resolved.

    So check the server you are attempting to download and store the WSUS content on.


    Wednesday, September 10, 2014 3:04 PM
  • I resolved this without running the console as Admin.  I went to Server Manager->Roles->File Services->Share and Storage Management, and then selected the following shares, "UpdateServicesPackages", WsusContent", and WSUSTemp", and edited both the NTFS and Share permissions for each adding the Domain groups we use for SCCM Admins and SCCM Site Servers.  I remember doing something like this for other SCCM 2012 instances I have put up as well.  

    A few additional notes:  

    A - The Servers proxy can cause similar issues, depending on your environment.  Check both those that appear to you in your browser and those used by the system account and exposed with the command, "netsh winhttp show proxy".  To easiest way to set them is in IE and then import them with, "netsh winhttp import proxy source=IE".

    B - The PatchDownLoader.log referred to earlier in this thread was not in a standard SCCM or WSUS log directory, but in this path, "C:\Users\<myAdminUserName>\AppData\Local\Temp\2".

    C - All this stems from something I see as a problem where WSUS and SCUP run in the context of the logged on user.  These problems can then be really amplified when you throw in Shavlik updates, and have a large environment with some delegated administration.

    Good luck all...Mark

    Monday, November 10, 2014 5:34 PM
  • Thank you! Ran console as an Admin. It's working fine now.
    Wednesday, January 14, 2015 1:58 PM
  • Neither changing the permissions on the share nor running the console as administrator helped me initially.

    I got more aggressive with the file permissions, and I managed to break my SCCM installation altogether (the SQL database files and the patches folder were on the same volume.  Doh!).  I had to run a repair on SQL and a repair on SCCM to get it working again, which only got me back to this same problem.  However, at that point when I tried running the console as administrator, that made this particular problem go away.Thanks for your help!


    Friday, October 30, 2015 6:00 PM