Friday, June 15, 2012

KB 2720211 Kills WSUS

Updates were performed on a client's WSUS 3.0 SP2 server this week and KB 2720211 killed WSUS. Here are the symptoms we saw:
  • WSUSDB in single user mode (done as part of the failed update process, but not undone when the update failed)
  • Named pipes disabled (also I think done as part of the failed update process).
  • MMC for WSUS fails with "MMC has detected an error in a snap-in"
After doing some research, it seems that this update causes a problem for some servers and not others. This particular server Windows Server 2008 R2 64-bit. I'm not sure if that is part of the issue.

The resolve is:
  • Use SQL Server Configuration Manager to enable named pipes
  • Use SQL Server Management Studio to change the database to MULTI_USER
    • Stop the Windows Update service and World Wide Web Publishing service before connecting to allow you to use the single connection that is available.
  • Copy some files manually from the update into their correct location. I'm not sure why but it appears on some systems this is not being done.
    • Download and run WSUS-KB270211-x64.exe /extract to extract the files.
    • Use a program capable of extracting CAB files (7 zip) to open PCW_CAB_SUS and copy the files DbCert, DbCertDll, and DbCertSql
    • Rename those files to WSUSSignDb.cer, WSUSSignDb.dll, and WSUSSignDb.sql.
    • Copy the cer and dll file to: C:\Windows\Sysmsi\ssee\mssql.22005\mssql\schemasig
    • Copy the sql file to C:\Program Files\Update Services\Database
  • Rerun the update
Some others have also reported that there is a DCOM error that needs to be resolved.

For a great detailed description of how to resolve this look for the post by chucker2 in the microsoft forum link:
Some others have reported that a registry key needed to be modified in order for the update to install properly. Or perhaps, this is just an easier fix than the above. See this link:
Posted by at

27 comments:

  1. AnonymousJune 19, 2012 at 10:05 AM

    I'm noticing an issue on all clients that utilize the WSUS server. KB2720211 is installed and I'm not sure if this is the cause or not. The clients basically state that the Windows Update Agent needs to be installed. When it attempts to install from WSUS, it fails with error 8007041B. In the update history, you can see that it tried to install WUA ver. 7.6.7600.256. Not sure if this failure is related to KB2720211 or how to resolve this.

    ReplyDelete
  2. AnonymousJune 21, 2012 at 7:44 PM

    I can't find the PCW_CAB_SUS cab file. When I run the extract all I get is Install.bat and WUSSetup.msp.

    Thanks for your help.

    ReplyDelete
  3. Byron WrightJune 21, 2012 at 8:47 PM

    The PCW_CAB_SUS cab file is in WUSSetup.msp. Extract the files from WUSSetup.msp by using 7 Zip and you're on your way.

    ReplyDelete
  4. Byron WrightJune 21, 2012 at 8:49 PM

    I've not seen the client problem above in conjunction with KB2720211. So, I can't say whether it's related.

    ReplyDelete
  5. GlenJune 22, 2012 at 12:37 PM

    Thanks Byron! Worked for us on 2003 Std SP2, though we didn't see the DCOM issue.
    Cheers

    ReplyDelete
  6. AnonymousJune 25, 2012 at 8:15 AM

    Thanks so much, I would not have had a clue

    ReplyDelete
  7. AnonymousJune 27, 2012 at 6:17 PM

    This worked perfectly on my Windows Server 2008 R2 server. Thanks!

    ReplyDelete
  8. AnonymousJune 29, 2012 at 10:24 AM

    OMG it worked I've been farking around with this for days! Uninstalling, reinstalling, failed uninstalls, tearing hair out. Tracking down Windows Install Cleanup utility.

    That KB completely hosed my WSUS on 2003. (not on my 2003R2, 2008 nor 2008R2 boxes though). After completely redoing my WSUS install and NOT installing KB272011, the clients couldn't connect* anyway because they had already got the WU-hardening patch.

    (*WARNING: Digital Signatures on file C:\WINDOWS\SoftwareDistribution\SelfUpdate\Default\wuident.cab are not trusted: Error 0x800b0001)

    Thank you very much!

    And thanks to Microsoft, CIA/NSA/Mossad/Iran for making last week so special! NOT

    ReplyDelete
  9. AnonymousJuly 10, 2012 at 3:49 PM

    None of the posts fixed for me. I used the log in the temp folder of the profile I was logged in with to resolve the update issue (mWusCa.log) Basically it was privs connecting to the database. Since I wasn't logged in with the id that originally attached the sus db to the databaseserver, I first gave dbo to the id I was logged in with on the sus server. Then MWusCa.log changed next time I tried to install & had a message that I needed either dbo or sql sysadmin role. I added the sus computer account to the sql sysadm role on the database server & got it to install. I also had a com+ error which I fixed early on so I'm unsure if it helped resolve the issue. I tracked it back to the com+ package named MsDtsServer. I found it by searching the registry using the guid that showed up in my event log (system log). Then I just opened component services & added the id shown in the event log with local launch & local activation.

    Its worth noting that the Yukon key was set to 0 on my sus server so going that route wasn't an option (plus it needs to connect to the db to run some scripts)

    ReplyDelete
    Replies
    1. AnonymousSeptember 20, 2012 at 3:08 AM

      Hi.

      I had the same issue as this. I was logged in with an account with local admin rights but no rights on the SQL database.

      When i logged in as a user with sufficient rights on the sql server the hotfix installed without any errors and my console opened again :)

      Delete
    2. KellyCDecember 13, 2012 at 3:53 PM

      Finding the mWusCa.log you mentioned helped me solve my problem. I thought I had the same issue but the problem actually was mirroring the SUS server. Once I broke the mirror the update ran fine. Of course, I had to rebuild it after that but at least I got the patch installed.

      Delete
  10. AnonymousJuly 10, 2012 at 5:31 PM

    Well this specific post didn't do it but it got me on the right track. I was able to fix it on Windows 2008 R2 by extracting the update and running the MSP manually (there were no CABs). It gave me a handful of nonfatal errors about writing to registry keys but in the end succeeded.

    I was 99% over my paranoia about automatic patching/updating before this. Now I'm back in rehab.

    ReplyDelete
  11. AnonymousJuly 11, 2012 at 8:02 AM

    Thanks! worked for us wihtous the SQL part.
    First I changed the HKEY_LOCAL_MACHINE\Software\Microsoft\Update Services\Server\Setup\wYukonInstalled to 0
    Run the update and changed it back to 1.

    than:
    ◦Download and run WSUS-KB270211-x64.exe /extract to extract the files.
    ◦Use a program capable of extracting CAB files (7 zip) to open PCW_CAB_SUS and copy the files DbCert, DbCertDll, and DbCertSql
    ◦Rename those files to WSUSSignDb.cer, WSUSSignDb.dll, and WSUSSignDb.sql.
    ◦Copy the cer and dll file to: C:\Windows\Sysmsi\ssee\mssql.22005\mssql\schemasig
    ◦Copy the sql file to C:\Program Files\Update Services\Database
    •Rerun the update again..

    this fixed our problem.

    Martijn

    ReplyDelete
    Replies
    1. AnonymousJanuary 23, 2013 at 6:24 AM

      This is what exactly worked for me, thank you for this blog entry!

      Delete
  12. Sebastiaan van WeeldenAugust 8, 2012 at 3:16 AM

    Just downloaded manually KB2720211 again and installed it.
    Works again. Thanx though for this great post!

    ReplyDelete
  13. AnonymousAugust 27, 2012 at 3:59 PM

    Worked for us on Server 2008 R2 x64 without additional registry hacking or DCOM fixes, exactly following your description.
    I was going nuts with that issue,thanks a thousand times!

    ReplyDelete
  14. AnonymousSeptember 5, 2012 at 11:30 AM

    I managed to fix my Windows 2008 R4 64bit WSUS Server by downloading KB2720211. Extract WUSSetup.msp from WSUS-KB2720211-x64.exe with 7-Zip (free utility). Once done just run WUSSetup.msp (a simple double click will do the job). You'll get a few error messages. Just click ignore. When the program has finished installing, reboot server and start your WSUS Console. All should be up and running beautifully.

    ReplyDelete
  15. AnonymousSeptember 14, 2012 at 7:37 AM

    Thank you so much for this blog... You saved the day for our college..........

    ReplyDelete
  16. dspOctober 12, 2012 at 6:18 AM

    tnx a lot.

    ReplyDelete
  17. AnonymousOctober 30, 2012 at 5:50 AM

    I had this same issue.the WSUS runs on a windows server 2003. My clients computer started to get updates after installing the KB2720211 update. but the synchronization process stopped. After restarting the server, the synchronization issue was fixed.

    ReplyDelete
  18. GuyDecember 21, 2012 at 10:28 AM

    I also had this problem but I was using the Microsoft internal database.

    Once I had reinstalled WSUS I applied KB2734608 which contains KB2720211. This brought WSUS up to date and got it functioning again :)

    ReplyDelete
  19. AnonymousJanuary 8, 2013 at 4:09 AM

    KB2734608 installed an WSUS broke
    KB2720211 was allredy installed and worked

    ReplyDelete
  20. AnonymousFebruary 21, 2013 at 1:15 PM

    Just ran into this on a virgin 2003 server install (using the internal db and not sql). Took two days to find this, and it worked. The only thing I actually had to do was extract and copy the WSUSSignDb.sql. Stopped IIS and Update services, reran the update and it worked fine.

    ReplyDelete
  21. AnonymousFebruary 21, 2013 at 1:29 PM

    Thank you!!!

    ReplyDelete
  22. AnonymousMay 5, 2014 at 4:26 AM

    Thanks a LOT !!!!!!
    I have the same probleme and your issue are succeffully resolve this issue !

    ReplyDelete
  23. AnonymousMarch 24, 2015 at 4:46 PM

    Turns out for us that it was as simple as being on the WSUS server as the SQLDBA account and running the update. Our SQL database was on a remote server.

    ReplyDelete
  24. jayaJuly 30, 2019 at 7:17 AM

    This comment has been removed by a blog administrator.

    ReplyDelete

Subscribe to: Post Comments (Atom)