Solved, Cured, Fixed - Windows Update Error 0x80244019

    General discussion

  • In the past several months I have upgraded WSUS on a Server 2012 Standard installation, and did a clean install of WSUS on the same. For both, the final WSUS version was 6.2.9200.17646  The issue on both was the same. Windows 7 computers were seen by WSUS, but the status never changed from "not yet reported". After days of trying to figure it out and following numerous and countless so-called solutions I found on the Internet – and not just on Microsoft support sites, it became apparent that even Microsoft was clueless as to the true *root cause* of the problem, and while many of the so-called solutions offered were just patches, not fixes. I realized I was just another guinea pig in their fruitless and unsuccessful attempts to find that root cause. It got to the point where I just gave up and using group policy set up all Windows 7 computers to get their updates directly from Microsoft.

    When dealing with a large number of Windows 7 machines, getting updates directly from Microsoft would really tie up bandwidth every Monday during the day, since many of the machines are turned off over the weekend and holidays. The slowdowns weren’t only noticeable; they made the network overall excruciatingly slow for the entire day. When users would reboot their computers thinking that would solve their problem, the entire update process for that computer would just start over, adding to the time the available bandwidth was maxed out. The buffer bloat on the Internet modem contributed even more to the bandwidth issue.  So with the onset of the new year and the fact that business was slowing down for me, I decided to tackle this issue and actually "solve" it….not "patch" it. I succeeded.

    First, I found a client with a perfectly working WSUS version 6.2 on Server 2012 Standard and began looking for differences. Of course, I found lots of them. It took me over two weeks to find the difference that solved the problem once and for all.  It seems that on the working WSUS, it had three file directories with files, that neither of the non-working WSUS setups had. To test this, I temporarily removed these three directory paths and their contents from the working WSUS, and found that I was getting the same exact error as on the non-working setups.

    On the non-working setups, reviewing the windowsupdate.log file on the windows 7 computers, they all had the same error.

    WARNING: WU client failed Searching for update with error 0x80244019
    >>##  RESUMED  ## AU: Search for updates [CallId = {C70DBC7D-66FD-40B0-AB20-0A9E9EF92081}]
    # WARNING: Search callback failed, result = 0x80244019
    # WARNING: Failed to find updates with error code 80244019

    While the Callid GUID may be different, the error 0x80244019 was consistent. Understand that this is but one of hundreds of issues that can generate this same exact error. If it were up to me, the description for error 0x80244019 would be "We haven’t got a clue!"  Yet upon adding the missing directories and their subsequent files, everything cleared up and has worked perfectly since.  So here’s what you need to to.

    First, stop the WSUS Service. From an elevated command prompt enter

    Net stop WSUSService

    Now ensure the three following paths exist, assuming you installed WSUS to it’s default location.

    C:\Program Files\Update Services\SelfUpdate\WSUS3\ia64\win7sp1

    C:\Program Files\Update Services\SelfUpdate\WSUS3\x64\win7sp1

    C:\Program Files\Update Services\SelfUpdate\WSUS3\x86\win7sp1

    If necessary, create the win7sp1 directory in each of the three directory paths, if it doesn’t already exist. Then copy the following files from the exact source directory indicated, to the exact destination directory indicated.

    For 64-bit Windows 7

    Copy the contents of C:\Windows\WinSxS\amd64_updateservices-selfupdate-x64-win7sp1_31bf3856ad364e35_6.2.9200.17025_none_ae5ccf24bda5b809 to C:\Program Files\Update Services\SelfUpdate\WSUS3\x64\win7sp1

    Note that it may be necessary to create the win7sp1 subdirectory.

    For 32-bit Windows 7

    Copy the contents of C:\Windows\WinSxS\amd64_updateservices-selfupdate-x86-win7sp1_31bf3856ad364e35_6.2.9200.17025_none_1043c229991acc59 to C:\Program Files\Update Services\SelfUpdate\WSUS3\x86\win7sp1

    Note that it may be necessary to create the win7sp1 subdirectory.

    For Itanium based (IA64) Windows 7

    Copy the contents of C:\Windows\WinSxS\amd64_updateservices-selfupdate-ia64-win7sp1_31bf3856ad364e35_6.2.9200.17025_none_84d35a4d6a8284f3 to C:\Program Files\Update Services\SelfUpdate\WSUS3\ia64\win7sp1

    Note that it may be necessary to create the win7sp1 subdirectory.

    When done, from an elevated command prompt restart the WSUS service.

    Net start wsusservice

    Then restart all the Windows 7 computers and in about a hour they will have all "checked in" with WSUS and will be getting updates.

    I still can’t comprehend why the many versions of the windows update diagnosis program that many have downloaded, don’t check for accessibility to that win7sp1 directory along with the other directories for other versions of windows, and simply report that it’s inaccessible or non-existent on the WSUS server. For a so-called diagnosis program, it appears to not be a very good one, since it doesn’t diagnose something as elementary as the existence of a required path and file, and report that to the user in plain English if it’s the problem.  Even further, it would appear that the routines which install the WSUS role on the server is not all inclusive of what needs to be installed and present for a fully functional WSUS. So it is of my unprofessional and uneducated opinion that Microsoft needs to fix the problem at the role installation source. Maybe then, they can do away with wasting time on a program to diagnose it, since it would appear to not diagnose this specific issue anyway. I'm done ranting. Thanks for reading. I feel better now. :)

    Sunday, December 25, 2016 9:13 PM

All replies

  • Hi Carl,

    Thanks for sharing the information with us. It's highly appreciated!

    Best Regards,


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Monday, December 26, 2016 6:03 AM
  • Hi, I already had the directory with files in them, so what else could there be if this does not solve it? I can See the Computers from WSUS mmc, but they have not been reporting for some time.. did as you and changed to getting updates from Microsoft. Now I have recreated the Wsus server, (removed and added the Role)tweaked the GPO controlling access and added the Http://wsusServer fully qualified domain name. for example. The client PC can Ping Wsus server, also connect (well see the iis) using explorer http://wsus-1 

    Daniel Törnstam Senior IT-technician Megger Sweden AB

    Monday, July 17, 2017 9:46 AM
  • Hi Daniel,

     Understand I'm no WSUS expert. I don't even qualify as a geek for this. I'm barely on the first rung of being a noob. :) I'm also assuming that this is "in fact" dealing with Windows 7 Pro computers, and not a newer version of the operating system.

    Is this true for all of your Windows 7 computers? Only the 64-bit versions maybe?

    In most cases I've found that patience is the issue. If I try to force an update with wuauclt /reportnow or /detectnow, that doesn't always work. I just have to wait it out. It's been awhile since I dealt with this issue, but as I recall some computers finally reported in after an hour or so, and for a few they took darn near an entire 24 hour cycle. But they did report in.

    One thing you can try is to first delete all computers from the WSUS console, then from an elevated command prompt run:

    c:\Program Files\Update Services\Tools\Wsusutil.exe postinstall /servicing

    Do note that there is NOT a slash or backslash preceeding the postinstall switch.

    Wait about 15-20 minutes at least, then stop/start the WSUSService and wait it out for a few hours. If you want, it wouldn't hurt to do the following on the problem windows 7 computers either.

    From an elevated command prompt run:

    cd c:\windows

    net stop wuauserv

    net stop bits

    net stop cryptsvc

    rmdir /s softwaredistribution #press "Y" when prompted to allow the directory to be deleted#

    del windowsupdate.log  #This just deletes the log, as it's probably hugh my now and you may need to see how update service on the workstation starts#

    Then restart the workstation, log on to the desktop if necessary and walk away for a few hours. (Maybe 3 at the most will be fine)

    Let's see if it's reporting in then. If not, then check the windowsupdate.log file on the workstation and lets see what you find there.

    Monday, July 17, 2017 3:39 PM
  • It's been almost nine months since my original post on this, and ran into this issue again on Server 2016 Standard. All the directories were there, the permissions were right - yet still got the same error. But only on Win 7 32-bit. Win 7 64-bit was no issue. So I deleted the contents of the C:\Program Files\Update Services\SelfUpdate\WSUS3\x86\win7sp1 directory and copied them fresh from the C:\Windows\WinSxS\amd64_updateservices-selfupdate-x86-win7sp1_31bf3856ad364e35_6.2.9200.17025_none_1043c229991acc59 and rebooted. That cleared everything up. So I can only figure that while the needed directory and contents were there, one or more of the files may have been corrupt. So when checking, just because the files are present, don't assume they're good.
    Sunday, August 06, 2017 2:29 PM
  • If what Carl says doesn't fix your problem, then you may take a look at Intranet Address specified for WSUS clients (Probably through Group Policy in active directory), so for error 0x8004419 check Intranet Address in this policy location on your Active Directory server:

    Run: GPMC.msc

    Open the policy designated for WSUS config,

    Go to: Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Windows Update and open: Specify intranet Microsoft update service location policy.

    and then change the address like: http://wsus to http://wsus:8530 or http://wsus:8531

    (Add Port number at the end of WSUS server name),

    after that run: GPUPDATE /force on Active directory server and after that on client and check to see if the error got fixed.

    TCP Ports 8530 and 8531 are default ports for WSUS service, to check these ports run this command on your WSUS server and look for similar ports listening on and [::] addresses:

    netstat -a -n

    Good Luck


    • Edited by ((MAK)) Tuesday, January 02, 2018 8:49 AM
    Tuesday, January 02, 2018 8:47 AM