none
KB4043961 WSUS not installing

    Question

  • Hey

    After upgrading some machines to 1709 i set WSUS to install KB4043961 on all machines. However it doesnt look to be doing this.

    All 1709 machines say they are missing this update. I tried to script:

    net stop bits
    net stop wuauserv
    net stop appidsvc
    net stop cryptsvc

    ETC.....

    But still wont.

    Any idea?

    Cheers


    Mark

    Tuesday, October 31, 2017 12:25 PM

All replies

  • I am seeing this same issue on my win server 2016 WSUS and Win server 2012 r2 WSUS server.

    Neither will download the update, but machines are showing it is needed.


    Tuesday, October 31, 2017 2:13 PM
  • I renamed "software distribution" folder and checked for updates.

    My PC found the KB and applied it.

    MS really needs to fix this issue.

    Tuesday, October 31, 2017 2:26 PM
  • Not via WSUS?

    Mark

    Tuesday, October 31, 2017 2:37 PM
  • Not via WSUS?

    Mark

    I found this in another thread, and decided to test.

    You need to rename "software distribution" folder on the endpoint (windows OS)

    Then I rebooted and checked for updates. My machine brought down the update via WSUS.


    Regarding delete/rename "software distribution" folder please check the following articles :

    https://www.windowscentral.com/how-clear-softwaredistribution-folder-windows-10

    https://www.xtremerain.com/modify-software-distribution-folder/


    Tuesday, October 31, 2017 3:19 PM
  • Not via WSUS?


    Mark

    I found this in another thread, and decided to test.

    You need to rename "software distribution" folder on the endpoint (windows OS)

    Then I rebooted and checked for updates. My machine brought down the update via WSUS.


    Regarding delete/rename "software distribution" folder please check the following articles :

    https://www.windowscentral.com/how-clear-softwaredistribution-folder-windows-10

    https://www.xtremerain.com/modify-software-distribution-folder/


    Hey

    Its worked on one of my machines, will try a few more :)


    Mark

    Wednesday, November 01, 2017 12:22 PM
  • This is a major bug when your talking 100's of computer's on a WSUS server.

    I guess I am not too surprised MS had not fixed this issue.

    Friday, November 03, 2017 12:59 PM
  • This is a major bug when your talking 100's of computer's on a WSUS server.

    I guess I am not too surprised MS had not fixed this issue.

    It is, i have 130 and that's enough to cause an issue for me.

    Guess i will need to run a script....


    Mark

    Friday, November 03, 2017 1:27 PM
  • Is there no better solution? Manual resets of the software distro are extreme.
    Monday, November 06, 2017 4:23 PM
  • I am getting the same issue, strangely though if you get PCs to check from MS Update instead of WSUS, the KB is found and installed ok.

    Will either have to wait for a fix or manually go round 200 systems!

    Derek

    Tuesday, November 07, 2017 4:38 PM
  • I am getting the same issue, strangely though if you get PCs to check from MS Update instead of WSUS, the KB is found and installed ok.

    Will either have to wait for a fix or manually go round 200 systems!

    Derek

    Get yourself https://www.dameware.com

    You can simply connect to each machine and run the command in Command Prompt without the user knowing a thing.

    Also does remote control so you can use the machine as if you was there.


    Mark

    Tuesday, November 07, 2017 5:30 PM
  • We are also having this problem with the clients not pulling the KB4043961 update from WSUS after a 1709 update.  It will pull it from the Microsoft servers.  We do not use Trend Micro.


    Tuesday, November 07, 2017 7:45 PM
  • We have over 250 PCs that cannot download and install KB4043961 using WSUS.  They have upgraded to 1709 and are now broken.  Microsoft FIX THIS!  I am not wiping out windows update history and deleting softdist folder on every single pc....  unreal...
    Thursday, November 09, 2017 5:06 PM
  • We have over 250 PCs that cannot download and install KB4043961 using WSUS.  They have upgraded to 1709 and are now broken.  Microsoft FIX THIS!  I am not wiping out windows update history and deleting softdist folder on every single pc....  unreal...

    Try using my script on the WSUS Server. No joke, it fixes tons of problems and may fix this one. I don't have anyone that I know who has been using my script to have the issue you're talking about. I agree, running a script to clean out 250+ pc's softwaredistribution folder is nasty.

    Have a peek at my Adamj Clean-WSUS script. It is the last WSUS Script you will ever need!

    http://community.spiceworks.com/scripts/show/2998-adamj-clean-wsus

    What it does:

    1. Add WSUS Index Optimization to the database to increase the speed of many database operations in WSUS by approximately 1000-1500 times faster.
    2. Remove all Drivers from the WSUS Database (Default; Optional).
    3. Shrink your WSUSContent folder's size by declining multiple types of updates including by default any superseded updates, preview updates, expired updates, Itanium updates, and beta updates. Optional extras: Language Packs, IE7, IE8, IE9, IE10, Embedded, NonEnglishUpdates, ComputerUpdates32bit, WinXP.
    4. Remove declined updates from the WSUS Database.
    5. Clean out all the synchronization logs that have built up over time (configurable, with the default keeping the last 14 days of logs).
    6. Compress Update Revisions.
    7. Remove Obsolete Updates.
    8. Computer Object Cleanup (configurable, with the default of deleting computer objects that have not synced within 30 days).
    9. Application Pool Memory Configuration to display the current private memory limit and easily set it to any configurable amount including 0 for unlimited. This is a manual execution only.
    10. Checks to see if you have a dirty database, and if you do, fixes it. This is primarily for Server 2012 WSUS, and is a manual execution only.
    11. Run the Recommended SQL database Maintenance script on the actual SQL database.
    12. Run the Server Cleanup Wizard.

    It will email the report out to you or save it to a file, or both.

    Although the script is lengthy, it has been made to be super easy to setup and use so don't over think it. There are some prerequisites and instructions at the top of the script. After installing the prerequisites and configuring the variables for your environment (email settings only if you are accepting all the defaults), simply run:

    .\Clean-WSUS.ps1 -FirstRun

    If you wish to view or increase the Application Pool Memory Configuration, or run the Dirty Database Check, you must run it with the required switch. See Get-Help .\Clean-WSUS.ps1 -Examples

    If you're having trouble, there's also a -HelpMe option that will create a log so you can send it to me for support.


    Adam Marshall, MCSE: Security
    http://www.adamj.org

    Thursday, November 09, 2017 5:38 PM
  • We have over 250 PCs that cannot download and install KB4043961 using WSUS.  They have upgraded to 1709 and are now broken.  Microsoft FIX THIS!  I am not wiping out windows update history and deleting softdist folder on every single pc....  unreal...

    Try using my script on the WSUS Server. No joke, it fixes tons of problems and may fix this one. I don't have anyone that I know who has been using my script to have the issue you're talking about.

    Well, now you do.

    It "may fix this one," you say. You constantly tout your script all over the WSUS world as some sort of panacea, regardless of whether it actually deals with the problem.

    I have a new, clean test 2012 WSUS I set up a few months ago just for testing Windows 10 feature updates (to 1703). I brought this out of storage and added Security Updates to find it doesn't deploy KB4043961 either.

    So decided to try the last script I will ever need, after of course updating it to the latest version.

    *** WARNING *** -FirstRun will decline every superseded update, even if it's APPROVED and NEEDED! That means that because I am still testing 1709, it has wiped out about 8 gigabytes of content I actually WANTED for bringing older versions up to 1703. "Wow, look how much it's cleaned up," you might say. But that's the point of having content in the first place. We don't all have unlimited, gigabit internet you know...

    -DirtyDatabaseCheck considers my database dirty every single time it runs. It throws this error...

    Msg 208, Level 16, State 1, Server TESTWSUS\MICROSOFT##WID, Line 12Invalid object name 'tbFile'.

    ...then announces it is fixed. But in reality, it screws the database right up. It wipes out almost all updates entirely, including KB4043961. They can't be found in the are declined list either. I expect they may be deleted, or possibly marked expired but not declined, though I really don't know.

    The only way I could get the missing updates back was to remove Windows 10 from the Products, hit 'Apply', add them again, and resync the whole lot back again.

    Your script breaks my test WSUS. And I tried it all several times, from scratch. It's a damned good thing I kept a backup. There's no way I am running it on my production WSUS, and I honestly can't recommend it to anyone else to try to fix KB4043961 not installing.

    No sir, that is the last time I will be running the last script I will ever need.  I'll stick with the regular WSUSDBMaintenance each patch day.

    Friday, November 10, 2017 4:22 AM
  • You constantly tout your script all over the WSUS world as some sort of panacea, regardless of whether it actually deals with the problem.

    95% of issues exist because there are a lack of knowledge in the WSUS Space. Microsoft developed this software a long long time ago for a small set of updates, with the ability to expand. Don't forget, it is called 'windows' update server.... not 'Microsoft' update server. Although 'Windows' updates are plentiful now and have conglomerated to be 'Microsoft Updates', they didn't used to be. They didn't have too many 'versions' of Windows to deal with, they didn't have the 'extra applications' within WSUS that they do now.

    Someone at Microsoft a long time ago made a 'great' (and I do truly mean great) decision to centralize all updates to all Microsoft products. The problem - WSUS was not meant for it and over the years, it has become problematic. Certain people in certain environments have issues and they are investigated and fixed by MS, other TechHeads, and eventually published on the web. The problem - unless you have that problem and search and find it, the WSUS Administrator doesn't know about it. The more of these that come out, the harder it is to find 'all the pieces' of the puzzle as the puzzle keeps expanding. Windows 10 caused an issue, 1607 RTM caused an issue, .NET 4.7 causes issues, etc.

    What from my script specifically fixes these issues - ALL OF IT - in combination. As an IT Person, you should know that there are too many variables and possibilities of errors in any software system. It's the right combination of these possibilities that cause heartbreaks, crashes, etc from bugs that the software developer didn't know about, didn't see, didn't program for.

    -------------------

    So now getting to the next part

    That means that because I am still testing 1709, it has wiped out about 8 gigabytes of content I actually WANTED for bringing older versions up to 1703.

    Actually, Feature upgrade 1709 is NOT a superseding update!!!

    So my script would not have touched 1703 or earlier 'feature upgrades' of Windows 10. (Except in the fixing of the Dirty Database, because it has to - Please see: https://support.microsoft.com/en-us/help/3194588 for more information about it.)

    -----------------------

    -DirtyDatabaseCheck considers my database dirty every single time it runs. It throws this error...

    You're right. I have a BUG in my script. in many cases the -DirtyDatabaseCheck DOES work, but in many cases like yours, it doesn't. The reason:

       

    As for your issue… After reviewing your environment, reviewing my code, reviewing the error, and reviewing the Dirty Database Check SQL Script, Add 1 line to the script and re-run it.

    After line 2656/2658 (depending if you have the one I modified yesterday), add a new line that reads:
    USE SUSDB

    The script will then look like:

    */
    USE SUSDB
    declare @NotNeededFiles table (FileDigest binary(20) UNIQUE);

    Re-Run –DirtyDatabaseCheck and I have a hunch that it will fix your problem as it was the fix for the many other's I've supported. The reason behind the problem (THE WHY) is that the login user has a different default database that the script is trying to run 'on', and it would probably be the 'master' database which definitely does not have the 'tbFile' table.

    -----------

    I'm human. I make mistakes. I'm the first to admit when I've made a mistake (and I did make one - I forgot to specifically say to use the SUSDB database - It's fixed in my next version). The speaking tone usually cannot be read from posts on the internet, however your crucifixion of my script and attack on me is premature, unwanted, and bears resemblance to an outburst of frustration. I could have easily thrown up my hands and moved on, but instead I'm trying to HELP you with your problem.


    Adam Marshall, MCSE: Security
    http://www.adamj.org




    • Edited by Adamj.org Friday, November 10, 2017 2:58 PM clarification even more.
    Friday, November 10, 2017 2:41 PM
  • FYI, I've done a bug fix for this and my script is now at version 3.2.

    Adam Marshall, MCSE: Security
    http://www.adamj.org

    Friday, November 10, 2017 11:50 PM
  • I wouldn't call it crucifixion and a personal attack. I would call it a scathing review. I do not mean to be personal and I understand that you want to help, and it's for the same that I provided my error result. But the fact remains that:

    1. you proposed your script as a probable fix, with no evidence whatsoever that it would fix the specific problem. And it doesn't.
    2. your site claims that your script was tested on the platform I run. And clearly it wasn't. It may have been once, but not since you heavily modified it.

    So if you think it's an unfair assessment, given the above points, I am somewhat unapologetic.

    Sure, we all make mistakesa and I make plenty. But for whatever reason, be it -runonce or -dirtydatabasecheck, your "tested" script destroyed my content. I would expect that not everyone has the luxury of a virtualized test WSUS that I enjoy. If I had run that on my only physical server, as some might be confident to do given that you script was "tested", I would be furious.

    Another suggestion in the spirit of helping each other, is that you might like to consider splitting -dirtydatabasecheck into -check and -fix, thus allowing a read only option like chkdsk without the /f.

    Finally, the 2017-11 updates for 1709 are out now and my untouched primary WSUS delivers it just fine, as it also does for every other update except 2017-10 for 1709. That suggests that problem was the update all along, and not the server.

    Wednesday, November 15, 2017 12:46 AM
  • Quoting: https://support.microsoft.com/en-us/help/3194588/-0xc1800118-error-when-you-push-windows-10-version-1607-by-using-wsus

    Order of steps
    1. Disable the “Upgrades” classification (USS or stand-alone WSUS)
    2. In Windows PowerShell ISE (admin), decline all Windows 10 upgrades.
    3. Remove all the upgrades for Windows 10 from the SUSDB.
    4. Delete files from the tbFile table in the WSUS database.
    5. Re-enable the classification in Windows PowerShell.
    6. Force a sync (PowerShell).

    Again, not my fault that it does it - I'm following Microsoft's way.

    Let's put this in an analogy. I make the car. You speed on the freeway. Police catch you. Who's fault? Mine for making the car, or yours for not understanding the ramifications of speeding. You may come back and say that I didn't let you know before that it was going to do that, and I would say you didn't know the highway traffic act either.

    Anyways, The reason why I don't have a check and a fix is that if you check it and it's fine, that's the end. If you check it and it's dirty, it needs to be fixed, so instead of running another command, it does it in succession - This makes it easy!

    You can't please everyone. Enjoy the optimization of WSUS as the first thing my script does is optimize the tables for you which speeds up WSUS by 1000-1500 times.

    And I've had 15 people report back since I released it in version 3.0 that the DirtyDatabaseCheck fixed their issues first time, without error, and only 2 including yourself in the last 2 weeks that encountered errors (which happen to have the same fix). All on 2012, 2012R2, and 2016, and those are just the ones that I know of. Everyone has a different environment, and it's quite amazing from a developer's point of view, how many different scenarios one has to program flawlessly to make it work seemlessly. What's even more amazing - I'm not a developer, and I hate programming.


    Adam Marshall, MCSE: Security
    http://www.adamj.org

    Wednesday, November 15, 2017 1:21 AM
  • And I've had 15 people report back since I released it in version 3.0 that the DirtyDatabaseCheck fixed their issues first time

    But not THIS issue. <sigh>

    To Mark, the OP, the answer now appears to be to deploy KB4048955.
    It deploys ok for me on x86 and x64. See if it works for you.


    • Edited by Dave Harry Wednesday, November 15, 2017 1:36 AM
    Wednesday, November 15, 2017 1:33 AM