locked
Third or fourth (maybe fifth?) WSUS server not working RRS feed

  • Question

  • Windows Server 2012 R2 Domain controller. Intsalled roles are RDGateway, AD DS, WSUS, DHCP and DNS. Has 30 plus windows 7 Pro workstations joined to the domain. WSUS apparently "broke" on or about the first week of April. Since that time, all workstations report "status not yet reported" in the WSUS console. However, the DC itself is the only one that does show a status and can get/install updates from the WSUS which is installed on that DC.

    As a test, I installed 2008 R2 on and old server computer from back at the shop, then installed/setup WSUS on it.  joined it to the domain, pointed a few workstations to use that WSUS, and they work just fine with no issues. This tells me (proves???) that there is no issue with any of the 30 plus workstations. The issue is on the WSUS itself.

    Here is a windowsupdate.log file from one of the workstations. Maybe this will help identify what the problem is on the WSUS side? From what I see, it looks like an issue with the authorization cookie. But that's just a WAG on my part based on no discernible facts what-so-ever.

    2016-06-09 14:50:56:486 1096 110 Misc ===========  Logging initialized (build: 7.6.7601.19161, tz: -0400)  ===========
    2016-06-09 14:50:56:486 1096 110 Misc   = Process: C:\Windows\system32\svchost.exe
    2016-06-09 14:50:56:486 1096 110 Misc   = Module: c:\windows\system32\wuaueng.dll
    2016-06-09 14:50:56:486 1096 110 Service *************
    2016-06-09 14:50:56:487 1096 110 Service ** START **  Service: Service startup
    2016-06-09 14:50:56:487 1096 110 Service *********
    2016-06-09 14:50:56:490 1096 110 Agent   * WU client version 7.6.7601.19161
    2016-06-09 14:50:56:491 1096 110 Agent   * Base directory: C:\Windows\SoftwareDistribution
    2016-06-09 14:50:56:491 1096 110 Agent   * Access type: No proxy
    2016-06-09 14:50:56:492 1096 110 Agent   * Network state: Connected
    2016-06-09 14:50:57:036 1096 110 DtaStor Default service for AU is {00000000-0000-0000-0000-000000000000}
    2016-06-09 14:50:57:037 1096 110 DtaStor Default service for AU is {9482F4B4-E343-43B6-B170-9A65BC822C77}
    2016-06-09 14:50:57:042 1096 110 Agent WARNING: failed to access the auth cab, fatal error 0x80070003
    2016-06-09 14:50:57:042 1096 110 Agent WARNING: Invalid service in the backup data store; cleaning up
    2016-06-09 14:50:57:043 1096 110 Agent WARNING: Failed to add and register service 7971f918-a847-4430-9279-4a52d1efe18d to the data store 0x80240031
    2016-06-09 14:50:57:043 1096 110 Agent WARNING: Default Service Recovery: Attempting to add pending registration for service 7971f918-a847-4430-9279-4a52d1efe18d to the data store
    2016-06-09 14:51:09:742 1096 e70 Report CWERReporter::Init succeeded
    2016-06-09 14:51:09:742 1096 e70 Agent ***********  Agent: Initializing Windows Update Agent  ***********
    2016-06-09 14:51:09:743 1096 e70 Agent   * Prerequisite roots succeeded.
    2016-06-09 14:51:09:743 1096 e70 Agent ***********  Agent: Initializing global settings cache  ***********
    2016-06-09 14:51:09:743 1096 e70 Agent   * WSUS server: http://odaserver:8530
    2016-06-09 14:51:09:743 1096 e70 Agent   * WSUS status server: http://odaserver:8530
    2016-06-09 14:51:09:743 1096 e70 Agent   * Target group: (Unassigned Computers)
    2016-06-09 14:51:09:743 1096 e70 Agent   * Windows Update access disabled: No
    2016-06-09 14:51:09:747 1096 e70 DnldMgr Download manager restoring 0 downloads
    2016-06-09 14:51:10:269 1096 110 Report ***********  Report: Initializing static reporting data  ***********
    2016-06-09 14:51:10:269 1096 110 Report   * OS Version = 6.1.7601.1.0.65792
    2016-06-09 14:51:10:269 1096 110 Report   * OS Product Type = 0x00000030
    2016-06-09 14:51:10:274 1096 110 Report   * Computer Brand = Dell Inc.
    2016-06-09 14:51:10:274 1096 110 Report   * Computer Model = Inspiron 3847
    2016-06-09 14:51:10:276 1096 110 Report   * Bios Revision = A04
    2016-06-09 14:51:10:276 1096 110 Report   * Bios Name = BIOS Date: 04/03/14 15:32:12 Ver: 04.06.05
    2016-06-09 14:51:10:276 1096 110 Report   * Bios Release Date = 2014-04-03T00:00:00
    2016-06-09 14:51:10:276 1096 110 Report   * Locale ID = 1033
    2016-06-09 14:51:42:046 1096 110 AU ###########  AU: Initializing Automatic Updates  ###########
    2016-06-09 14:51:42:047 1096 110 AU   # WSUS server: http://odaserver:8530
    2016-06-09 14:51:42:047 1096 110 AU   # Detection frequency: 1
    2016-06-09 14:51:42:047 1096 110 AU   # Approval type: Scheduled (Policy)
    2016-06-09 14:51:42:047 1096 110 AU   # Scheduled install day/time: Every day at 1:00
    2016-06-09 14:51:42:047 1096 110 AU   # Auto-install minor updates: Yes (Policy)
    2016-06-09 14:51:42:047 1096 110 AU   # Will interact with non-admins (Non-admins are elevated (Policy))
    2016-06-09 14:51:42:048 1096 110 AU Setting AU scheduled install time to 2016-06-10 05:00:00
    2016-06-09 14:51:42:049 1096 110 AU Successfully wrote event for AU health state:0
    2016-06-09 14:51:42:049 1096 110 AU Initializing featured updates
    2016-06-09 14:51:42:049 1096 110 AU Found 0 cached featured updates
    2016-06-09 14:51:42:050 1096 110 AU Successfully wrote event for AU health state:0
    2016-06-09 14:51:42:051 1096 110 AU Successfully wrote event for AU health state:0
    2016-06-09 14:51:42:051 1096 110 AU AU finished delayed initialization
    2016-06-09 14:52:34:615 1096 4cc AU Triggering AU detection through DetectNow API
    2016-06-09 14:52:34:615 1096 4cc AU Triggering Online detection (non-interactive)
    2016-06-09 14:52:34:616 1096 110 AU #############
    2016-06-09 14:52:34:617 1096 110 AU ## START ##  AU: Search for updates
    2016-06-09 14:52:34:617 1096 110 AU #########
    2016-06-09 14:52:34:618 1096 110 AU <<## SUBMITTED ## AU: Search for updates [CallId = {E2F98E62-E01E-4E41-8EAC-2FAB1E45883C}]
    2016-06-09 14:52:34:619 1096 9dc Agent *************
    2016-06-09 14:52:34:619 1096 9dc Agent ** START **  Agent: Finding updates [CallerId = AutomaticUpdates]
    2016-06-09 14:52:34:619 1096 9dc Agent *********
    2016-06-09 14:52:34:619 1096 9dc Agent   * Online = Yes; Ignore download priority = No
    2016-06-09 14:52:34:619 1096 9dc Agent   * Criteria = "IsInstalled=0 and DeploymentAction='Installation' or IsPresent=1 and DeploymentAction='Uninstallation' or IsInstalled=1 and DeploymentAction='Installation' and RebootRequired=1 or IsInstalled=0 and DeploymentAction='Uninstallation' and RebootRequired=1"
    2016-06-09 14:52:34:619 1096 9dc Agent   * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Managed
    2016-06-09 14:52:34:619 1096 9dc Agent   * Search Scope = {Machine}
    2016-06-09 14:52:34:619 1096 9dc Setup Checking for agent SelfUpdate
    2016-06-09 14:52:34:620 1096 9dc Setup Client version: Core: 7.6.7601.19161  Aux: 7.6.7601.19161
    2016-06-09 14:52:36:913 1096 9dc Misc Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wuident.cab with dwProvFlags 0x00000080:
    2016-06-09 14:52:36:943 1096 9dc Misc  Microsoft signed: NA
    2016-06-09 14:52:36:948 1096 9dc Misc Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\TMP4CD5.tmp with dwProvFlags 0x00000080:
    2016-06-09 14:52:36:984 1096 9dc Misc  Microsoft signed: NA
    2016-06-09 14:52:36:993 1096 9dc Misc WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80190194
    2016-06-09 14:52:36:993 1096 9dc Misc WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80190194
    2016-06-09 14:52:36:993 1096 9dc Misc WARNING: DownloadFileInternal failed for http://odaserver:8530/selfupdate/WSUS3/x86/Win7SP1/wsus3setup.cab: error 0x80190194
    2016-06-09 14:52:36:993 1096 9dc Setup WARNING: SelfUpdate check failed to download package information, error = 0x80244019
    2016-06-09 14:52:36:993 1096 9dc Setup FATAL: SelfUpdate check failed, err = 0x80244019
    2016-06-09 14:52:36:993 1096 9dc Agent   * WARNING: Skipping scan, self-update check returned 0x80244019
    2016-06-09 14:52:36:994 1096 9dc Agent   * WARNING: Exit code = 0x80244019
    2016-06-09 14:52:36:994 1096 9dc Agent *********
    2016-06-09 14:52:36:994 1096 9dc Agent **  END  **  Agent: Finding updates [CallerId = AutomaticUpdates]
    2016-06-09 14:52:36:994 1096 9dc Agent *************
    2016-06-09 14:52:36:994 1096 9dc Agent WARNING: WU client failed Searching for update with error 0x80244019
    2016-06-09 14:52:36:994 1096 744 AU >>##  RESUMED  ## AU: Search for updates [CallId = {E2F98E62-E01E-4E41-8EAC-2FAB1E45883C}]
    2016-06-09 14:52:36:994 1096 744 AU   # WARNING: Search callback failed, result = 0x80244019
    2016-06-09 14:52:36:994 1096 744 AU   # WARNING: Failed to find updates with error code 80244019
    2016-06-09 14:52:36:994 1096 744 AU #########
    2016-06-09 14:52:36:995 1096 744 AU ##  END  ##  AU: Search for updates [CallId = {E2F98E62-E01E-4E41-8EAC-2FAB1E45883C}]
    2016-06-09 14:52:36:995 1096 744 AU #############
    2016-06-09 14:52:36:999 1096 744 AU Successfully wrote event for AU health state:0
    2016-06-09 14:52:36:999 1096 744 AU AU setting next detection timeout to 2016-06-09 19:46:38
    2016-06-09 14:52:36:999 1096 744 AU Setting AU scheduled install time to 2016-06-10 05:00:00
    2016-06-09 14:52:37:000 1096 744 AU Successfully wrote event for AU health state:0
    2016-06-09 14:52:37:001 1096 744 AU Successfully wrote event for AU health state:0
    2016-06-09 14:52:41:993 1096 9dc Report REPORT EVENT: {B2930AB8-D141-4AC6-857E-982E84C657E3} 2016-06-09 14:52:36:993-0400 1 148 101 {D67661EB-2423-451D-BF5D-13199E37DF28} 1 80244019 SelfUpdate Failure Software Synchronization Windows Update Client failed to detect with error 0x80244019.
    2016-06-09 14:52:42:010 1096 9dc Report CWERReporter::HandleEvents - WER report upload completed with status 0x8
    2016-06-09 14:52:42:010 1096 9dc Report WER Report sent: 7.6.7601.19161 0x80244019(0) 67661EB-2423-451D-BF5D-13199E37DF28 Scan 1 0 SelfUpdate {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} 0
    2016-06-09 14:53:44:127 1096 9dc PT WARNING: Cached cookie has expired or new PID is available
    2016-06-09 14:53:44:127 1096 9dc PT Initializing simple targeting cookie, clientId = 98f038ea-0185-4c56-a65e-a06f119d83cb, target group = , DNS name = backoffice.oxforddental.local
    2016-06-09 14:53:44:127 1096 9dc PT   Server URL = http://odaserver:8530/SimpleAuthWebService/SimpleAuth.asmx
    2016-06-09 14:53:44:374 1096 9dc Report Uploading 1 events using cached cookie, reporting URL = http://odaserver:8530/ReportingWebService/ReportingWebService.asmx
    2016-06-09 14:53:44:379 1096 9dc Report Reporter successfully uploaded 1 events.

    Thursday, June 9, 2016 7:08 PM

Answers

  • Hello Anne! Good News!

    After weeks of head banging and trying everything under the sun known to mankind, I have FINALLY! Solved my WSUS “client not yet reported” problem on all five of my business client’s servers. To save time I will not elaborate on the process I went through over the last few weeks. Instead, I will make this post as short and to the point as feasibly possible, in the sincere hope that others will find it useful. I will start by first identifying the symptoms of this issue/problem. Second, I will identify how I confirmed the specific problem that was causing the symptoms. Finally, I will identify the definitive solution to this specific problem. Note that the symptoms I describe in the first part can be caused by many problems. So once the reader finds that their symptoms duplicate mine, you must confirm that the specific problem I experienced which caused my symptoms, is the same exact problem you are experiencing.

    Symptoms: For no discernable reason, I discovered around the first week of May 2015 that all 30 windows 7 professional 32-bit computers on one of my customer’s networks had not been getting updates from the WSUS server for over a month. Naturally, I simply uninstalled WSUS, deleted the WSUS directories (for the 2012 R2 server this was installed on, I deleted the C:\Program Files\Update Services directory, as well as the C:\WSUS directory where I had designated downloaded updates to be stored). Then using Studio management 2012 I connected to the WID database and detached the SUSDB database from WID. Next, I deleted the SUSDB and SUSDBLOG file from the C:\WINDOWS\WID directory and rebooted the server.

    Then I did a reinstall of the WSUS Server role. I found that upon completion of the reintall, I was unable to complete the post installation tasks. Found this was because the C:\Program Files\Update Services\Tools folder was not created during the reinstall, and therefore the post install program could not find the WsusUtil.exe file that was supposed to be in that directory.

    A search of C:\Windows\WinSXS found the WsusUtil.exe file I needed in the C:\Windows\WinSxS\amd64_updateservices-common_31bf3856ad364e35_6.2.9200.17166_none_76e72f6d2469b954 folder. I manually created the \Tools folder in the C:\Program Files\Update Services directory. Then I copied WsusUtil.exe from the C:\Windows\WinSxS\amd64_updateservices-common_31bf3856ad364e35_6.2.9200.17166_none_76e72f6d2469b954 directory, into the C:\Program Files\Update Services\Tools directory. After that, I was able to complete the post installation tasks and finish the installation and setup of WSUS.  Then I waited for a few hours.

    Hours later in the WSUS console all of those workstations appeared with a status of “not yet reported” and the only computer reporting was the WSUS server itself. That was it. All other workstations maintained a status of “not yet reported” for days. (I was not patient by choice on this)

    On one of the non-reporting workstations I ran the below script.

    -          - - - -

    Net stop wuauserv

    Net stop bits

    Net stop cryptsvc

    Rmdir %windir%\softwaredistribution

    Del %windir%\windowsupdate.log

    Net start cryptsvc

    Net start bits

    Net start wuauserv

    -          ------

    After running the script, I waited about a minute or two to give the workstation update program time to initialize. Then I executed wuauclt /resetauthorization /detectnow and waited a good 10 minutes.

    After my 10 minute wait, I copied the %windir%\windowsupdate.log to a flash drive and renamed it to updatenotworking.log

    Next, is disjoined this workstation from the domain and drove it 15 miles across town to another client of mine with a working WSUS server on a Server 2008 R2 machine. After joining it to the domain, I ran the same script above, waited a few minutes and executed a wuauclt /resetauthorization /detectnow command and waited another good 10 minutes. Then I pulled the newly created %windir%\windowsupate.log file and put in on my flashdrive.

    Next, I printed out the current windowsupdate.log file and the updatenotworking.log file and did a side-by-side comparison. Here’s the line that stuck out in the updatenotworking.log file.

    -          ----

    WARNING: DownloadFileInternal failed for http://<servername>:<portnum>/selfupdate/WSUS3/x86/Win7SP1/wsus3setup.cab: error 0x80190194

    -          -----

    PROBLEM: After the 15 mile drive back to the client with the problem WSUS, I checked, and on the WSUS server the Win7SP1 folder did not exist in the …./selfupdate/WSUS3/x86/ directory.

    SOLUTION:  I manually created the WIN7SP1 folder and also created it in the …/selfupdate/WSUS3/x64/ directory.

    Next, for the 32 bit version of Windows 7 I copied the contents of the C:\Windows\WinSxS\amd64_updateservices-selfupdate-x86-win7sp1_31bf3856ad364e35_6.2.9200.21142_none_10b4be3eb24b5800 directory to the C:\Program Files\Update Services\SelfUpdate\WSUS3\x86\Win7SP1 directory.

    For the 64-bit version of Windows 7 I copied the contents of the C:\Windows\WinSxS\amd64_updateservices-selfupdate-x64-win7sp1_31bf3856ad364e35_6.2.9200.21142_none_aecdcb39d6d643b0 directory to the c:\Program Files\Update Services\SelfUpdate\WSUS3\x64\Win7SP1 directory.

    Finally, I stopped and restarted the WSUS Service, and within minutes workstations started successfully checking in. Problem solved.

    I think someone on the WSUS team needs to take a look at this, as well as the failure for a reintall to not include the tools folder with the wsusutil.exe program in it.

    -Carl

    Saturday, June 11, 2016 6:14 AM

All replies

  • Hi Carl1959,

    1. Please check if you have installed KB3159706 on WSUS server 2012 R2, if yes, then we need to do manual steps to finish the installation, see detailed information in the KB:

    https://support.microsoft.com/en-us/kb/3159706

    2. Run server cleanup wizard and reindex WSUS database to do regular maintenance on WSUS server, check if it could help:

    Reindex the WSUS Database

    https://technet.microsoft.com/en-us/library/dd939795%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396

    3. Since you are using WSUS 2008 R2 instead, if the above methods couldn't help, I would suggest rebuilding your WSUS 2012 R2 and check the result.

    Best Regards,

    Anne


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.



    Friday, June 10, 2016 2:48 AM
  • Hi Carl1959,


    we also have a best practice for not installing WSUS on a domain controller:

    WSUS: WSUS should be installed on a non-domain controller

    https://technet.microsoft.com/en-us/library/ff646928(v=ws.10).aspx

    Best regards,

    Andrei


    We could change the world, if God would give us the source code.

    Friday, June 10, 2016 4:37 AM
  • All fine and dandy. "Should be" doesn't count here. It worked fine for over a year without so much as a burp. Now it upchucks all over the place, and your response is "should be" installed on a non-domain controller. Not very helpful at all. Unless of course, you have any server computers that meet the minimum requirements of my client that you would like to give to them at no charge? I myself have been trying for years to get the twenty dollar bill trees to bloom, and can't even get the penny bushes to sprout.

    Friday, June 10, 2016 5:35 AM
  • Hi Anne,

     I recall you trying to help with this issue from earlier posts I made also. Those were for different clients with this same exact issue. But I deeply appreciate your patience and willingness to help.  I'm cooled off a bit now, having reloaded the previous client's server from scratch. The other previous client is presently considering abandoning MS products all together, and I've not heard back from them yet on doing a server reload. If I never hear back from them, that tells me they've decided to go with Apple products - and I really can't blame them. Meanwhile, on the home front...........

    The 2008 R2 WSUS was just a temporary thing, to confirm the workstations are fine. I just couldn't see the problem being on the workstations, since it's highly doubtful the same issue would suddenly appear on 30 plus workstations all at once - unless MS released an update that effectively broke it on the workstation side. The 2008 WSUS has been pulled, as like I stated, that was only to confirm to myself that the issue was with the 2012 WSUS server, and not the workstations.

    Server cleanups are run weekly, using an automated powershell script.  I have run the cleanup manually per your request, and as expected there was very little cleanup to be done, since the script does it  weekly. While a few expired updates were deleted, it wasn't enough to register more than zero KB freed up.

    For KB3159706 I checked, and it’s already installed. I did follow the directions in the KB article to complete the post installation setup tasks though, and it executed successfully in about 20 seconds, give or take.

    Following directions in the technet article for rebuilding the database doesn’t appear to work.  I've ran into a bit of a snafu. I'm using the below command, slightly modified because I'm using WID. So ##SSEE is replaced with ##WID. Also, that website tells me I need the SQLCMD utility, but the website referenced in the article for that is no longer valid. (Note that I have Studio 2012 installed, not Studio 2005 as referenced on the web page). I've already unistalled WSUS and reinstall it. When I uninstalled it, I used Studio 2012 to disconnect and eradicate that database from WID, and even went so far as to manually delete the SUSDB and SUSDBLOG files from the hard drive after having removed the WSUS role. I deleted the internally generated backup copies of those files too. So the SUSDB file I have now is pure and clean (I would expect). So is there a need to reindex it still? If so, here's the command I'm running from a command window, followed by the error I get.

    c:\>sqlcmd -S np:\\.\pipe\MSSQL$MICROSOFT##WID\sql\query -I C:\WSUS\DBMaintenanceWsusDBMaintenance.sql

    Sqlcmd: ':\\.\pipe\MSSQL$MICROSOFT##WID\sql\query -I C:\WSUS\DBMaintenance\WsusDBMaintenance.sql': Unexpected argument. Enter '-?' for help.

    Note that I’m very apprehensive when it comes to SQL. I know just enough about SQL server to be dangerous. But at this point, I have nothing to lose. Since WSUS is broke already, I figure there’s very little I can do to make it *more* broke than it already is. J

    Anyway, After all the above, I attempted to run windows update on the workstation and before I could remove the mouse from  the “check for updates” link, got the “unable to check for updates” error. So with the exception that I cannot successfully run the rebuild, none of the above has made any difference.

    UPdate: Using Studio 2012, I ran the dbmaintenance.sql by right clicking the susdb database, new query and pasted it in. Ran it, and it ended with an execution successful. Since the business was closed I rebooted the server afterwards. Then checked it this morning and there's no change. The WSUS computer itself is reporting with no problem. But all the other workstations still show "not yet reported".

    • Edited by Carl1959 Friday, June 10, 2016 1:36 PM
    Friday, June 10, 2016 5:39 AM
  • Hello Anne! Good News!

    After weeks of head banging and trying everything under the sun known to mankind, I have FINALLY! Solved my WSUS “client not yet reported” problem on all five of my business client’s servers. To save time I will not elaborate on the process I went through over the last few weeks. Instead, I will make this post as short and to the point as feasibly possible, in the sincere hope that others will find it useful. I will start by first identifying the symptoms of this issue/problem. Second, I will identify how I confirmed the specific problem that was causing the symptoms. Finally, I will identify the definitive solution to this specific problem. Note that the symptoms I describe in the first part can be caused by many problems. So once the reader finds that their symptoms duplicate mine, you must confirm that the specific problem I experienced which caused my symptoms, is the same exact problem you are experiencing.

    Symptoms: For no discernable reason, I discovered around the first week of May 2015 that all 30 windows 7 professional 32-bit computers on one of my customer’s networks had not been getting updates from the WSUS server for over a month. Naturally, I simply uninstalled WSUS, deleted the WSUS directories (for the 2012 R2 server this was installed on, I deleted the C:\Program Files\Update Services directory, as well as the C:\WSUS directory where I had designated downloaded updates to be stored). Then using Studio management 2012 I connected to the WID database and detached the SUSDB database from WID. Next, I deleted the SUSDB and SUSDBLOG file from the C:\WINDOWS\WID directory and rebooted the server.

    Then I did a reinstall of the WSUS Server role. I found that upon completion of the reintall, I was unable to complete the post installation tasks. Found this was because the C:\Program Files\Update Services\Tools folder was not created during the reinstall, and therefore the post install program could not find the WsusUtil.exe file that was supposed to be in that directory.

    A search of C:\Windows\WinSXS found the WsusUtil.exe file I needed in the C:\Windows\WinSxS\amd64_updateservices-common_31bf3856ad364e35_6.2.9200.17166_none_76e72f6d2469b954 folder. I manually created the \Tools folder in the C:\Program Files\Update Services directory. Then I copied WsusUtil.exe from the C:\Windows\WinSxS\amd64_updateservices-common_31bf3856ad364e35_6.2.9200.17166_none_76e72f6d2469b954 directory, into the C:\Program Files\Update Services\Tools directory. After that, I was able to complete the post installation tasks and finish the installation and setup of WSUS.  Then I waited for a few hours.

    Hours later in the WSUS console all of those workstations appeared with a status of “not yet reported” and the only computer reporting was the WSUS server itself. That was it. All other workstations maintained a status of “not yet reported” for days. (I was not patient by choice on this)

    On one of the non-reporting workstations I ran the below script.

    -          - - - -

    Net stop wuauserv

    Net stop bits

    Net stop cryptsvc

    Rmdir %windir%\softwaredistribution

    Del %windir%\windowsupdate.log

    Net start cryptsvc

    Net start bits

    Net start wuauserv

    -          ------

    After running the script, I waited about a minute or two to give the workstation update program time to initialize. Then I executed wuauclt /resetauthorization /detectnow and waited a good 10 minutes.

    After my 10 minute wait, I copied the %windir%\windowsupdate.log to a flash drive and renamed it to updatenotworking.log

    Next, is disjoined this workstation from the domain and drove it 15 miles across town to another client of mine with a working WSUS server on a Server 2008 R2 machine. After joining it to the domain, I ran the same script above, waited a few minutes and executed a wuauclt /resetauthorization /detectnow command and waited another good 10 minutes. Then I pulled the newly created %windir%\windowsupate.log file and put in on my flashdrive.

    Next, I printed out the current windowsupdate.log file and the updatenotworking.log file and did a side-by-side comparison. Here’s the line that stuck out in the updatenotworking.log file.

    -          ----

    WARNING: DownloadFileInternal failed for http://<servername>:<portnum>/selfupdate/WSUS3/x86/Win7SP1/wsus3setup.cab: error 0x80190194

    -          -----

    PROBLEM: After the 15 mile drive back to the client with the problem WSUS, I checked, and on the WSUS server the Win7SP1 folder did not exist in the …./selfupdate/WSUS3/x86/ directory.

    SOLUTION:  I manually created the WIN7SP1 folder and also created it in the …/selfupdate/WSUS3/x64/ directory.

    Next, for the 32 bit version of Windows 7 I copied the contents of the C:\Windows\WinSxS\amd64_updateservices-selfupdate-x86-win7sp1_31bf3856ad364e35_6.2.9200.21142_none_10b4be3eb24b5800 directory to the C:\Program Files\Update Services\SelfUpdate\WSUS3\x86\Win7SP1 directory.

    For the 64-bit version of Windows 7 I copied the contents of the C:\Windows\WinSxS\amd64_updateservices-selfupdate-x64-win7sp1_31bf3856ad364e35_6.2.9200.21142_none_aecdcb39d6d643b0 directory to the c:\Program Files\Update Services\SelfUpdate\WSUS3\x64\Win7SP1 directory.

    Finally, I stopped and restarted the WSUS Service, and within minutes workstations started successfully checking in. Problem solved.

    I think someone on the WSUS team needs to take a look at this, as well as the failure for a reintall to not include the tools folder with the wsusutil.exe program in it.

    -Carl

    Saturday, June 11, 2016 6:14 AM
  • Hi Carl1959,

    It's highly appreciated that you record the detailed progress and resolution of the issue. The method to resolve "post-installation failure" and "not report" issue is very helpful.

    All in all, glad to hear you have solved the issue and thanks for your feeding back.

    Best Regards,

    Anne


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Monday, June 13, 2016 1:46 AM