Thursday, August 4, 2011

The process is not in background processing mode

When trying to download Software Updates in ConfigMgr it is possible that the following error message is displayed: "The process is not in background processing mode". When trying again the error message stays. Rebooting the ConfigMgr server doesn't help, so what to do next?


The solution is not that hard I think. It's BITS that's malfunction here! Just follow these steps to make it functional again:
  • Logon to the ConfigMgr server (which in my case is also the WSUS server)
  • Stop the Background Intelligent Transfer Service (BITS) service
  • Stop the Windows Update (WUAUSERV) service
  • Browse to the "Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader" folder and delete both files in here (qmgr0.dat and qmgr1.dat)
On Windows Server 2008 (R2) servers it's needed to give Everyone NTFS permissions to browse that folders. This because Everyone is by default on the deny list here.
  • Browse to the "C:\Windows" directory and delete the SoftwareDistribution folder in here
The SoftwareDistribution folder and qmgr0.dat/qmgr1.dat files will be created again after starting both services again.
  • Start the Windows Update (WUAUSERV) service again
  • Start the Background Intelligent Transfer Service (BITS) service again
  • Open the ConfigMgr console and start a "site wide software update synchronization" by right clicking on Software Updates > Software Repository and choose: Run Synchronization
After that downloading Software Updates will be functional again!


Note: When it's still not working after these steps, have a look at possible changes in the Proxy server configuration. Especially Authentication settings can do the trick here!

Update 28-2-2013: When Microsoft or third party updates are still not download after above change, just try the following: Edit Anonymous Authentication for the IIS website (by right clicking) and change it from a Specific User to Application pool identity.
Thanks to Kapil Dham for the solution on this.
Posted by Henk Hoogendoorn at 10:45 AM
Labels:

10 comments:

  1. AnonymousAugust 4, 2011 at 6:54 PM

    The error message should say "Invalid proxy server configuration or credentials"! :)

    ReplyDelete
  2. UnknownFebruary 27, 2013 at 10:09 PM

    Hello, apparently its working for me for Windows updates but not for third party catalogues I imported in SCUP 2011. It still fails despite executing the steps mentioned abov and synchnorizing the Update repository.

    ReplyDelete
    Replies
    1. Henk HoogendoornFebruary 28, 2013 at 9:10 AM

      Strange thing. SCUP does nothing more then publishing updates to ConfigMgr SUP. Is the error message the same as mentioned above?

      Delete
    2. UnknownFebruary 28, 2013 at 3:59 PM

      More info: I see the following error on PatchDownloader.log:
      HttpSendRequest failed HTTP_STATUS_FORBIDDEN or HTTP_STATUS_DENIED
      and

      ERROR: DownloadContentFiles() failed with hr=0x80070191

      We do not use any proxy settings on our servers and what's puzzling is that Windows Specific packages do get downloaded without issues using WSUS integrated SCCM.

      Delete
  3. UnknownFebruary 28, 2013 at 4:38 PM

    Ok, finally got it working!!! The issue was something that was related to

    HttpSendRequest failed HTTP_STATUS_FORBIDDEN or HTTP_STATUS_DENIED

    and

    ERROR: DownloadContentFiles() failed with hr=0x80070191.

    I saw these errors in PatchDownloader.log on SCCM server.

    Apparently the way the WSUS website was set up had incorrect settings specified for enabling Anonymous Authentication for the web site. I had to Edit Anonymous Authentication (by right clicking) and change it from a Specific User to Application pool identity.

    Once it was complete, I could download third party updates without any issue.

    ReplyDelete
    Replies
    1. Henk HoogendoornFebruary 28, 2013 at 9:59 PM

      Good news! Thanks for posting the solution on this blogpost. I will update it right away, so other people can use it also.

      Delete
    2. AnonymousFebruary 23, 2015 at 5:33 PM

      This saved my day. Thank you Kapil for sharing.

      Delete
    3. AnonymousFebruary 23, 2015 at 5:34 PM

      It seems every february this gets responded to. :)

      Delete
  4. AnonymousFebruary 12, 2014 at 8:47 PM

    This was the answer for me as well -
    "When Microsoft or third party updates are still not download after above change, just try the following: Edit Anonymous Authentication for the IIS website (by right clicking) and change it from a Specific User to Application pool identity. "

    Thank you!!!!

    ReplyDelete
  5. AnonymousDecember 11, 2015 at 10:43 AM

    Regarding your Update 28-2-2013: Why not just give read permissions for your IUSR to the WSUS/Content ? Application Pool Identity für WSUS is Network Service, which is the big gun for a tiny problem ;)

    ReplyDelete

Subscribe to: Post Comments (Atom)