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. :)