80244019 Windows update encountered an unknown error

80244019 Windows update encountered an unknown error

Windows update error 80244019 usually refers to an issue downloading the content from the WSUS server. If you look at the Windows Update Log located at %windir%WindowsUpdate.log you´ll probably find entries similar to the one below:

2012-07-30 08:52:57:322 904 b04 DnldMgr WARNING: BITS job {5EA16320-76A6-4D28-83EA-71C39D4FEA55} failed, updateId = {F308F044-A236-4AAD-AE49-DE35D5356FE3}.101, hr = 0x80190194, BG_ERROR_CONTEXT = 5
2012-07-30 08:52:57:322 904 b04 DnldMgr Progress failure bytes total = 1748400, bytes transferred = 0
2012-07-30 08:52:57:322 904 b04 DnldMgr Failed job file: URL = http://WSUSServer:8530/Content/7E/0DF360442FC0808CC47E2B73E45BC178D808227E.exe, local path = C:WindowsSoftwareDistributionDownloadfafd970530328d8e541b6ba8b873fbbc�df360442fc0808cc47e2b73e45bc178d808227e
2012-07-30 08:52:57:338 904 b04 DnldMgr Error 0x80244019 occurred while downloading update; notifying dependent calls.

As you can notice it indicates that Error 0x80244019 has occurred while downloading an update. Furthermost you can type in your browser the URL: http://WSUSServer:8530/Content/7E/0DF360442FC0808CC47E2B73E45BC178D808227E.exe and you´ll get a 404 error code. What this simply means is that that your client can not download the updates from the server as the web page does not offer them. Below are two reasons why this could be happening:

  1. Your web server does not support the necessary MIME/Types needed for proper WSUS functioning
  2. You actually don’t have that file present in your WSUS server
  3. General connectivity issue


Step 1: MIME Types not enabled on your content directory in IIS

Most people will come across Error 0x80244019 because of the MIME types apparently. Most of the answers I found online included the addition of them as the solution, while others wanted me to edit the registry. Regardless, as a first step after checking the windows update log file I would proceed to ensure that all the needed MIME types are registered. For that go to your IIS server and select the Content folder. There you can see the option to display all the MIME types for that folder. Many people make the mistake of checking directly against the root site, but these needs to be done at the Content level folder. There look for the following 4 types and if one is missing make sure to add it:

.cab – application/octet-stream
.msp – application/octet-stream
.msi – application/octet-stream
.psf – application/octet-stream


In my particular case I had all the MIME types so I proceeded to the next step. As I mentioned above if you check for them on the root site you might find that .psf is not there but that would not be an issue.

Step 2: The files are not present on your content directory in the server´s hard drive

Another reason why Error 0x80244019 might be happening is that you don’t actually have the files the client is looking for in your hard drive. There are a number of reasons why this could be happening. In my particular scenario I used the Windows Small Business Server 2011 Management Console (Backup and Server Storage -> Server Storage -> Move Windows Update Repository Data) and for some reason some of the updates went missing. If you ever by accident delete files from the content directory this would also apply to you. In order to identify this what you must do is the following:

  1. Go to the log file as mentioned above and find an instance that failed to download and obtain the URL
  2. Go to the URL and confirm that you get the 404 message
  3. Go to your WSUS server and browse to the location where the content (updates) are stored ( For example: C:WSUSWsusContent )
  4. Navigate to the folder structure where your update file should be located. If it is not there then you are missing files.

To resolve this is fairly simple although it took me sometime to find out the solution. You must start a command line prompt with Administrator credentials. After that you are going to use the WSUSutil.exe. You can find it usually on this path: %drive%Program FilesUpdate ServicesTools and can read more about it on this technet article. After you browse to the location of the WSUSutil.exe tool you must execute the following command:

WSUSutil.exe reset


You use this command if you store updates locally on your WSUS server and want to ensure that the metadata information stored in your WSUS database is accurate. With this command, you verify that every update metadata row in the WSUS database corresponds to update files stored in the local update file storage location on your WSUS server. If update files are missing or have been corrupted, WSUS downloads the update files again. This command might be useful to run after you restore your database, or as a first step when troubleshooting update approvals.

As described above using the reset parameter will force WSUS to re-download any corrupted or missing files again from Windows Update. After performing this command I was able to use WSUS again.

Step 3: General conectivity issues

The last reason why Error 0x80244019 might show up is just a general connectivity issue. Assume you can reach the WSUS server but then connectivity is lost which would cause this issue. Another reason would be a firewall or poorly configured IIS that causes the content directory to be inaccessible.

Enhanced by Zemanta

You may also like...

4 Responses

  1. Hannah Lewis says:

    hey I tried all the solutions and it didn’t work… any other ideas

  2. Amanda Edmunds says:

    Try this.

    1. Click Start – Run, type regedit and press enter.
    2. Navigate to the following Registry key



    3. Once in, from the right-pane, change the value of the key
    4. Reboot the Windows Vista PC and that should fix the problem.
    After completing these steps, try to check for a Windows Update again. In case the problem persists, proceed to this website

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.