none
WSUS 3.0 SP2 will not run after installing update 2720211

    Question

  • http://support.microsoft.com/kb/2720211

    The update was installed and server rebooted.  Now the WSUS console on Server 2008 SP2 will not run.  "Error: Connection Error.  An error occurred trying to connect to WSUS server."

    The update service and IIS are both running.

    When checking for updates from clients, they  show a message saying their update software needs to be upgraded, but they fail updating.

    I was going to uninstall the update, but there is no option to uninstall the update from the WSUS server.

    What are options to fix this?


    • Edited by MyGposts Monday, June 11, 2012 8:21 PM
    Monday, June 11, 2012 8:20 PM

Answers

  • well, like everyone else I encountered this. I was trying to get it up so I could migrate it. This was on Server2003 with the embedded database.

    initial status:

    Update installed via WSUS update and system rebooted. Permission errors for database. Console can't connect.

    My Fix based on some forum posts from other wsus issues was to...

    D/L offline 2720211 installer
    change HKEY_LOCAL_MACHINE\Software\Microsoft\Update Services\Server\Setup\wYukonInstalled from 1 to 0
    install update again
    reboot
    change HKEY_LOCAL_MACHINE\Software\Microsoft\Update Services\Server\Setup\wYukonInstalled from 0 to 1
    reboot
    install update AGAIN

    Friday, June 15, 2012 2:52 PM
  • I successfully recovered WSUS without changing too much - hopefully this will work for others. The catch is you have to have a recent backup of your WSUS database.

    Step 1: Download the KB2720211 from Microsoft: http://support.microsoft.com/kb/2720211

    Step 2: Open Regedit, and change the value of this DWORD to 0: "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup\wYukonInstalled"

    Step 3: Install KB2720211

    Step 4: Change the DWORD value back to 1

    Step 5: Stop the SQL database service (I used Windows Internal Database, so it is MSSQL$MICROSOFT##SSEE)

    Step 6: Delete the DB files in *:\WSUS\UpdateServicesDbFiles (SUSDB.mdf & SUSDB_log.ldf)

    Step 7: Restore the SUSDB.mdf & SUSDB_log.ldf from backup

    Step 8: Start the SQL database service

    Step 9: Start the "Update Services" service

    At this point, WSUS should be functional again. I proceeded to run a synchronization and the cleanup wizard on it, but I believe at this point it is working properly.


    Friday, June 15, 2012 12:11 AM
  • WSUS KB2720211 : Common issues encountered and how to fix them - The WSUS Support Team Blog - Site Home - TechNet Blogs:
    http://blogs.technet.com/b/sus/archive/2012/06/20/wsus-kb272011-common-issues-encountered-and-how-to-fix-them.aspx

    (And I'm not sure who flagged this post as abusive, but as a person who's trying to get the WSUS team to acknowledge issues with this update, it's not appreciated one bit.  All I'm trying to do with this post is help people and for someone to flag it as abusive is hurtful to me.  The reason I posted it was to at least show that the WSUS team is aware of it.  Given that commenting on the blog post is typically the best way to get feedback to the team, go pile on the comments there rather than flagging my post of merely the blog url as abusive.

    I didn't code the patch.  I'm just trying to get to the bottom of the issue.)

    Friday, June 22, 2012 5:15 PM

All replies

  • Here is more detail error:

    The WSUS administration console was unable to connect to the WSUS Server Database.
        
    Verify that SQL server is running on the WSUS Server. If the problem persists, try restarting SQL.
        

    System.Data.SqlClient.SqlException -- Cannot open database "SUSDB" requested by the login. The login failed.
    Login failed for user 'NT AUTHORITY\NETWORK SERVICE'.

    Source
    .Net SqlClient Data Provider

    Stack Trace:
       at Microsoft.UpdateServices.Internal.BaseApi.SoapExceptionProcessor.DeserializeAndThrow(SoapException soapException)
       at Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccessProxy.ExecuteSPGetTargetGroupById(Guid id)
       at Microsoft.UpdateServices.Internal.BaseApi.ComputerTargetGroup.GetById(Guid id, UpdateServer updateServer)
       at Microsoft.UpdateServices.Internal.BaseApi.UpdateServer.GetComputerTargetGroup(Guid id)
       at Microsoft.UpdateServices.UI.AdminApiAccess.AdminApiTools.GetUpdateServer(String serverName, Boolean useSecureConnection, Int32 portNumber)
       at Microsoft.UpdateServices.UI.SnapIn.Scope.ServerSummaryScopeNode.GetUpdateServer(PersistedServerSettings settings)
       at Microsoft.UpdateServices.UI.SnapIn.Scope.ServerSummaryScopeNode.ConnectToServer()
       at Microsoft.UpdateServices.UI.SnapIn.Scope.ServerSummaryScopeNode.ConnectToServerAndPopulateNode(Boolean connectingServerToConsole)
       at Microsoft.UpdateServices.UI.SnapIn.Scope.ServerSummaryScopeNode.OnExpandFromLoad(SyncStatus status)

    Monday, June 11, 2012 8:38 PM
  • I was going to patch the servers w/ this update this week, but going to hold off now.

    Anyone else run into this?

    Let us know if you find a solution MyGposts!

    Monday, June 11, 2012 8:53 PM
  • I see that the error says it can't connect to the database now using the login of NT AUTHORITY\NETWORK SERVICE, but no changes were made to the database.
    Monday, June 11, 2012 8:59 PM
  • This update broke my WSUS and I have been trying all day to repair it. Uninstalling the updates do not work and nothing has worked thus far. I am at the point where I am going to rebuild my WSUS.
    Monday, June 11, 2012 10:06 PM
  • I had the same error after this update and i fixed it by correcting the "DistributedCOM" Error i had in the System-Eventlog (Assigning Local Launch Permission). Do you also have a DCom Error in the Logs?
    Tuesday, June 12, 2012 7:47 AM
  • Hi,

    I have the same issue

    I install KB2720211 & reboot the wsus server. since, it is not possible to open the admin console

    I have this on system event:

    **********************************************************************************

    La console d'administration WSUS n'a pas été en mesure de se connecter à la base de données du serveur WSUS.
        
    Vérifiez que le serveur SQL est en cours d'exécution sur le serveur WSUS. Si le problème persiste, essayez de relancer SQL.
       
    System.Data.SqlClient.SqlException -- Cannot open database "SUSDB" requested by the login. The login failed.
    Login failed for user 'DOMAIN\SERVER_NAME$'.

    Source
    .Net SqlClient Data Provider

    Stack Trace:
       à Microsoft.UpdateServices.Internal.BaseApi.SoapExceptionProcessor.DeserializeAndThrow(SoapException soapException)
       à Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccessProxy.ExecuteSPGetTargetGroupById(Guid id)
       à Microsoft.UpdateServices.Internal.BaseApi.ComputerTargetGroup.GetById(Guid id, UpdateServer updateServer)
       à Microsoft.UpdateServices.Internal.BaseApi.UpdateServer.GetComputerTargetGroup(Guid id)
       à Microsoft.UpdateServices.UI.AdminApiAccess.AdminApiTools.GetUpdateServer(String serverName, Boolean useSecureConnection, Int32 portNumber)
       à Microsoft.UpdateServices.UI.SnapIn.Scope.ServerSummaryScopeNode.GetUpdateServer(PersistedServerSettings settings)
       à Microsoft.UpdateServices.UI.SnapIn.Scope.ServerSummaryScopeNode.ConnectToServer()
       à Microsoft.UpdateServices.UI.SnapIn.Scope.ServerSummaryScopeNode.ConnectToServerAndPopulateNode(Boolean connectingServerToConsole)
       à Microsoft.UpdateServices.UI.SnapIn.Scope.ServerSummaryScopeNode.OnExpandFromLoad(SyncStatus status)

    **********************************************************************************

    impossible to uninstall the kb (from msiexec /X, patch.exe /u, from add/removre prg)

    do you have a solution?

    Tuesday, June 12, 2012 9:17 AM
  • Have you checked the permissions on the SQL Server Database Engine for the SUSDB Database?
    Tuesday, June 12, 2012 9:43 AM
  • What must be the permission?

    i use a sql database on a different server

    Tuesday, June 12, 2012 9:53 AM
  • Same incident happened with our setup.

    Only extra thing was the server hardware issue which got resolved after one reboot.

    OS is working fine.

    MMC is giving error " MMC has detected an error in a snap-in and will unload it"

    Update for Windows Server Update Services 3.0 SP2 for x64-based Systems (KB2720211) is not getting installed.
    Error Code : 643 Windows Update Encountered an unknown error.

    Update Service is not getting started.

    @Microsoft Support : Any possible Solution???


    .::[ashX]::.


    • Edited by ashx Tuesday, June 12, 2012 10:11 AM one more line added
    Tuesday, June 12, 2012 10:07 AM
  • Hi!

    Can you describe in detail what you did and which "DistributedCOM" you worked on/with?

    Thanks in advance!

    Tuesday, June 12, 2012 11:20 AM
  • I am having the same problem.

    I don't know if this is significant but I looked at the database using SQL Server management Studio and I noticed that SUSDB is in single user mode. I don't know if it's always been like that and I haven't tried switching it to multi user.


    • Edited by icosa Tuesday, June 12, 2012 11:38 AM
    Tuesday, June 12, 2012 11:38 AM
  • Hi!

    Can you describe in detail what you did and which "DistributedCOM" you worked on/with?

    Thanks in advance!

    My error in detail:

    The application-specific permission settings do not grant Local Launch permission for the COM Server application with CLSID

    {24FF4FDC-1D9F-4195-8C79-0DA39248FF48}

    and APPID

    {B292921D-AF50-400C-9B75-0C57A7F29BA1}

    to the user NT AUTHORITY\SYSTEM SID (S-1-5-18) from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.

    I opened the Component Services and looked for this APPID in Computers\My Computer\DCOM Config (set View to Detail to make the Application ID visibile). In my case it was the "NAP Agent Service". Then i opened the properties of this service and edited the Launch and Activision Permissions (Security Tab) according to the error message (Local Launch Allowed for SYSTEM).

    If you have Windows Server 2008 R2, you have to give yourself permission to change the settings of the Component Service by looking for the APPID in the windows Registy under HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID. Then change the permissions of the Key by taking ownership of the object and give Full Permissions to the local Administrator-Group. After that you can change the DCOM Permissions in the Component Services.

    Tuesday, June 12, 2012 11:40 AM
  • What must be the permission?

    i use a sql database on a different server


    Judging by your error message, the Computer Account of your WSUS-Server should have db_owner on the SUSDB Database.
    Tuesday, June 12, 2012 11:42 AM
  • Hi,

    the server is DBO for the database

    Tuesday, June 12, 2012 2:07 PM
  • In addition to Ickis99's DCOM fix, I also found that I needed to reenable named pipes for the MICROSOFT##SSEE instance, since WSUS connects to its DB using named pipes.

    1. Open the Sql Server Configuration Manager (Start > Programs > Microsoft SQL Server 2008 R2 > Configuration Tools)
    2. SQL Server Network Configuration  > Protocols for MICROSOFT##SSEE
    3. Open Properties for Named Pipes and set Enabled to Yes.

    You have to restart the service to get this change to take effect, but I took the lazy way out and just rebooted the server. My WSUS still isnt' working yet, but the amount of errors is continuing to go down.

    • Proposed as answer by V3Bok Tuesday, October 09, 2012 2:44 PM
    Tuesday, June 12, 2012 3:10 PM
  • Check if the SERVERNAME$ Object is listed in Security\Logins in SQL Management Studio. In the Properties of this Object, in "User Mapping", "db_owner" must be checked for the SUSDB Database.

    Edit: Maybe there is a problem with the Object itself. You can try to re-add the Server-Object into the SQL-Server Logins. I cant think of any other possibilities how the Object can have the correct permission on the DB, while you get a specific error message stating otherwise.

    • Edited by Ickis99 Tuesday, June 12, 2012 3:43 PM
    Tuesday, June 12, 2012 3:15 PM
  • I've tried, but I can't connect to the SQL instance. I suspect that the initial failed install has done something to the database to lock it, so after the DCOM/named pipes thing I decided to try the 2720211 install again to see if it would finish properly.

    1. Rebooted server.
    2. Ran "iisreset /stop"
    3. Stopped the "Update Services" service.
    4. Ran "WSUS-KB2720211-x64.exe" downloaded from Microsoft.

    After a short period of time the install failed. Digging through the event logs gave me a log file I could look at where the installer has added tables/views/etc to the SUSDB database. At the end is this note:

    Creating view PUBLIC_VIEWS.vComputerInventory
    Creating TVF PUBLIC_VIEWS.fnUpdateInstallationStateMap
    Could not find file 'C:\Program Files\Update Services\Database\WSUSSignDb.sql'.
       at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
       at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
       at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy)
       at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
       at System.IO.StreamReader..ctor(String path, Encoding encoding, Boolean detectEncodingFromByteOrderMarks, Int32 bufferSize)
       at System.IO.StreamReader..ctor(String path, Boolean detectEncodingFromByteOrderMarks)
       at System.IO.File.OpenText(String path)
       at Microsoft.UpdateServices.Setup.ExecuteSql.ExecuteSql.Main(String[] args)
    Starting WSUSService...
    WSUSService is now started.
    StartServer completed successfully.

    I've looked for this "WSUSSignDb.sql" file without success.

    Tuesday, June 12, 2012 3:52 PM
  • Upon further investigation, it appears that the WSUSSignDb.sql file is supposed to come from KB2720211 itself. This time I monitored the "C:\Program Files\Update Services\Database" directory during the install. A new version of "mwus_database_schema.sql" and "popdb.sql" are placed during the install process, but "WSUSSignDb.sql" never appears. It seems that the installer is not placing the file where it's supposed to go.

    In addition, I have tried the hotfix referenced in this KB article where WSUSSignDb.sql is sourced, KB2530678. That install also fails for the same reason.

    I've even tried to extract the sql file and place it directly, but I can't seem to get anything out of the MSP file. Even MSIX and WinRAR can't seem to get at its contents.

    Tuesday, June 12, 2012 6:42 PM
  • I have 2 identical servers (2008 R2). One failed, one succeeded. I've made no changes to the failed one.

    Once people are out of the office, I will reboot with the missing files and see if the install goes through.

    Here's the rest of the log for the successful installation:

    Executing string: CREATE CERTIFICATE [MS_SchemaSigningCertificateE551E6B950285A04DCDBEF0363CD0DAB24381B40] FROM FILE = 'C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\SchemaSig\wsussigndb.cer'
    Warning: The certificate you created is expired.
    Executing string: ALTER CERTIFICATE [MS_SchemaSigningCertificateE551E6B950285A04DCDBEF0363CD0DAB24381B40] ATTESTED BY 'C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\SchemaSig\WSUSSignDb.dll'
    Signing object:[dbo].[spGetComputerSummariesForTargetGroup]

    (ETC. ETC. A bunch of files get signed and the service gets started.)
    EDIT: In C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\SchemaSig
    WSUSSignDb.cer and WSUSSignDb.dll get replaced with files dated 2012. Copies of those files are present, along with WSUSSignDb.sql in the database directory.

    • Edited by Cacasapo Tuesday, June 12, 2012 10:33 PM
    Tuesday, June 12, 2012 10:26 PM
  • Copying the files from the good install to the locations mentioned above and reapplying the patch took care of it. I'm up and just got done synching.
    I suppose it's against policy to post links to files, so extracting them may be the only "easy" way to get this going.
    Wednesday, June 13, 2012 12:08 AM
  • There seems to be several different stories here but I think my problem was that SUSDB was in single user mode.

    This is on Windows 2003 SBS.

    I applied KB2720211 via the automatic update. The update failed and then WSUS wouldn't run for more than a minute or so. I used SQL Server Express Management Studio and discovered SUSDB to be in single user mode.  I switched it to multi-user this morning but that did not get WSUS working again. Tonight I applied KB2720211 again. This time it succeeded and, after a reboot, WSUS is working fine. I'm pretty sure that is the only change I made.

    Good luck


    • Edited by icosa Wednesday, June 13, 2012 2:13 AM
    Wednesday, June 13, 2012 2:12 AM
  • On 32-bit Windows Server 2008 here.  All same symptoms.  To get my WSUS resuscitated, avoiding a total rebuild:

    1. shut down MSSQL instance and moved corrupt db file and log aside (DB was left in single-user mode after failed update)

    2. restored files from backup (C:\WSUS\UpdateServicesDbFiles\SUSDB.mdf and SUSDB_log.ldf )

    3. restarted DB, but WSUS wouldn't sync up to Microsoft until I rebooted the server

    May attempt the drop-in files fix mentioned by Cacasapo later with the bad update, but want my systems to get the updates right about now.

    Wednesday, June 13, 2012 2:43 AM
  • A tenuous idea so far but I'm wondering about the size of the SUSDB (mdf & ldf) from systems that are failing.
    Wednesday, June 13, 2012 4:59 AM
  • In case of emergency - keep cool -- Okay, we try...support call to ESC Deutschland (ESCde) - Microsoft Gold Certified Partner to contact MS...waiting!

    In case of emergency do things that seem not to help - okay, we did, too.

    Took the Install Package of WSUS3SP2 (WSUS-KB2720211-x86.exe), extracted it with 7zip step by step - (--> WUSSetup.msp --> PCW_CAB_SUS --> ended up with directory "PCW_CAb_SUS" containing several files - some are starting with DB: DBCert, DbCertDll, DbCertSql - renamed them with .crt - to get info of used certs.  DbCertDll.crt, DbCertSql.crt failed - no valid cert inside. But "DBCert.crt" seems to cert-File.

    BUT:

    - Untrusted (on WSUS Server - owner: CN = MS_SchemaSigningCertificateE551E6B950285A04DCDBEF0363CD0DAB24381B40)

    - expired ( 16.03.2012 ! )

    Hm... not sure if this untrusted, expired certificate might be part of the problem ?!

    Is this Cert probably trusted at someone's server (not having the problems on their WSUS server?)

    Beside this, the .sql command file for the upgrade process of the WSUS-DB can be found in the folder with the extraceted files, too: "MwusSchema" with 17649 code lines.

    Probably the problem can be found inside there, too. Unfortunately I am not a SQL-geek :( Volunteers needed! )

    @MS: How about informing about the problem on the KB article side? 

    Comments welcome!

    All this does not seem to help solving the problem for us, but might be helping finding the reason for it.

    Greetings from north of Germany,

    BSM - Kiel

    P.S. At the moment our WSUS server is hardend against Flame: it burned down :(

    Wednesday, June 13, 2012 10:04 AM
  • SUSDB.mdf - 2.61gb
    SUSDB_log.ldf - 517mb

    Wednesday, June 13, 2012 11:22 AM
  • "Good" Version of DB - before patching:

    SUSDB.mdf - 3,64 GB

    SUSDB_log.ldf - 240 MB

    Same size after false run of WSUS3SP2 - Hotfix

    • Proposed as answer by immensenet Wednesday, May 22, 2013 5:05 PM
    Wednesday, June 13, 2012 11:35 AM
  • OK, so 'small' db's (I take it from failed systems).

    so much for that idea.

    Wednesday, June 13, 2012 11:38 AM
  • Hi,

    just a little info.

    my database is on a separate SQL server. the base was nammed SUSDBserver_pro

    when i install on the WSUS server the KB2720211, a base was created: SUSDB......

    really a f...g patch, with no roll back for the moment.

    I open a ticket on MS. still waiting a solution

    Wednesday, June 13, 2012 12:16 PM
  • Okay. I managed to get my WSUS install running again, with a set of very complicated steps. While I have done a few other things trying to make this work, I believe these are the more "generic" steps.

    • Fix the DCOM issue (thanks Ickis99) - Check for DistributedCOM event 10016 in the System Event log for APPID {B292921D-AF50-400C-9B75-0C57A7F29BA1}

    1. If you have Windows Server 2008 R2, you have to give yourself permission to change the settings of the Component Service by looking for the APPID in the windows Registy under HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID. Then change the permissions of the Key by taking ownership of the object and give Full Permissions to the local Administrator-Group. After that you can change the DCOM Permissions in the Component Services.
    2. Open Administrative Tools > Component Services
    3. Within Component Services, open Computers > My Computer > DCOM Config
    4. Find the NAP Agent Service, right-click it, and open Properties.
    5. Under the security tab, hit "Edit..." under the Launch and Activation Permissions section.
    6. Give the SYSTEM user allow for Local Launch.

    • Enable Named Pipes for the local SQL Server Express install - Check for MSSQL$MICROSOFT##SSEE event 18456 in the Application event log

    1. Open the Sql Server Configuration Manager (Start > Programs > Microsoft SQL Server 2008 R2 > Configuration Tools)
    2. SQL Server Network Configuration  > Protocols for MICROSOFT##SSEE
    3. Open Properties for Named Pipes and set Enabled to Yes.

    • Put the SUSDB database back into multi-user mode (might not be necessary, but I did it)

    1. Open a command prompt as administrator and run "iisreset /stop"
    2. Stop the "Update Services" service if running (it usually isn't since it's broken at this point)
    3. Open SQL Server Management Studio as Administrator (Start > Programs > Microsoft SQL Server 2008 R2)
    4. Under Server type, select "Database Engine", for server name, use "\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query", and for Authentication use "Windows Authentication". Click Connect.
    5. Look at your SUSDB (Databases > SUSDB). If it is in single-user mode, open its properties, go to the Options screen, and set the Restrict Access setting to "MULTI_USER". Let it reset connections if needed.
    6. Reboot your server (might not be necessary, but I figured it was best to play it safe)
    7. You might see a lot of MSSQL$MICROSOFT##SSEE event 33002 in the logs after the reboot, but you can ignore these for now since the patch "should" fix it in a bit.

    • Extract necessary files from 2720211 installer

    1. Download the KB2720211 installer for your architecture from Microsoft (http://support.microsoft.com/kb/2720211)
    2. Extract WUSSetup.msp from the installer by running the installer with the /extract parameter (example: "WSUS-KB2720211-x64.exe /extract")
    3. With 7-zip, open WUSSetup.msp and extract "PCW_CAB_SUS".
    4. With 7-zip, open "PCW_CAB_SUS" and extract "DbCert", "DbCertDll", and "DbCertSql".
    5. Rename those files to "WSUSSignDb.cer", "WSUSSignDb.dll", and "WSUSSignDb.sql", respectively.
    6. On your WSUS server, navigate to "C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\SchemaSig" and copy the extracted "WSUSSignDb.cer" and "WSUSSignDb.dll" to it. Make a backup copy of the two existing versions, just in case.
    7. On your WSUS server, navigate to "C:\Program Files\Update Services\Database" and copy the extracted "WSUSSignDb.sql" to it. Make a backup copy of any existing versions of the file.

    At this point, you should (cross your fingers!) be able to try reinstalling the 2720211 patch and see if it finishes. If it does, your WSUS should be back to normal. I realize that this was a lot of steps, but this is what I did to get my server up and running again. I hope it works for you!





    • Edited by chucker2 Wednesday, June 13, 2012 1:50 PM more formatting
    • Proposed as answer by chucker2 Wednesday, June 13, 2012 2:26 PM
    Wednesday, June 13, 2012 1:48 PM
  • Ok, i have very similar issue, but with 403 Forbidden.
    Mine WSUS running in SSL secured mode. When i disable it (after installation of this KB2720211) - sync works perfectly. So, maybe this able to give a direction ?

    Instead of enabling an SSL on local website ServerSyncWebService - i left this open and was able to sync succesfully.
    but in help topic about SSL in WSUS it says to put it require SSL. And BEFORE 2720211 it was working while enabled.
    • Edited by warpil Wednesday, June 13, 2012 4:08 PM
    Wednesday, June 13, 2012 4:04 PM
  • Extract necessary files from 2720211 installer

    1. Download the KB2720211 installer for your architecture from Microsoft (http://support.microsoft.com/kb/2720211)
    2. Extract WUSSetup.msp from the installer by running the installer with the /extract parameter (example: "WSUS-KB2720211-x64.exe /extract")
    3. With 7-zip, open WUSSetup.msp and extract "PCW_CAB_SUS".
    4. With 7-zip, open "PCW_CAB_SUS" and extract "DbCert", "DbCertDll", and "DbCertSql".
    5. Rename those files to "WSUSSignDb.cer", "WSUSSignDb.dll", and "WSUSSignDb.sql", respectively.
    6. On your WSUS server, navigate to "C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\SchemaSig" and copy the extracted "WSUSSignDb.cer" and "WSUSSignDb.dll" to it. Make a backup copy of the two existing versions, just in case.
    7. On your WSUS server, navigate to "C:\Program Files\Update Services\Database" and copy the extracted "WSUSSignDb.sql" to it. Make a backup copy of any existing versions of the file.
  • So I noticed in the failure logs that the WSUSSignDb.sql didn't exist, and had extracted the install, but wasn't sure which file it was, so I wanted to thank you for giving me the correct locations and names of the files.  I can't explain how upset I am that this happened.  This is patching 101 and Microsoft screwed the pooch big time here.  I even said to one of my guys "Against my better judgement, I'm going to patch WSUS potentially before all of the clients have the updates." and it almost bit me.  The .SQL file contains all of the hashes for the signatures of files and when it couldn't validate them, it was failing. 

    I'm not sure about the other errors, but the full version of what I quoted should absolutely be the solution and someone at M$ needs their tail kicked for this failure.

    Wednesday, June 13, 2012 7:34 PM
  • Extract necessary files from 2720211 installer

    1. Download the KB2720211 installer for your architecture from Microsoft (http://support.microsoft.com/kb/2720211)
    2. Extract WUSSetup.msp from the installer by running the installer with the /extract parameter (example: "WSUS-KB2720211-x64.exe /extract")
    3. With 7-zip, open WUSSetup.msp and extract "PCW_CAB_SUS".
    4. With 7-zip, open "PCW_CAB_SUS" and extract "DbCert", "DbCertDll", and "DbCertSql".
    5. Rename those files to "WSUSSignDb.cer", "WSUSSignDb.dll", and "WSUSSignDb.sql", respectively.
    6. On your WSUS server, navigate to "C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\SchemaSig" and copy the extracted "WSUSSignDb.cer" and "WSUSSignDb.dll" to it. Make a backup copy of the two existing versions, just in case.
    7. On your WSUS server, navigate to "C:\Program Files\Update Services\Database" and copy the extracted "WSUSSignDb.sql" to it. Make a backup copy of any existing versions of the file.

    So I noticed in the failure logs that the WSUSSignDb.sql didn't exist, and had extracted the install, but wasn't sure which file it was, so I wanted to thank you for giving me the correct locations and names of the files.  I can't explain how upset I am that this happened.  This is patching 101 and Microsoft screwed the pooch big time here.  I even said to one of my guys "Against my better judgement, I'm going to patch WSUS potentially before all of the clients have the updates." and it almost bit me.  The .SQL file contains all of the hashes for the signatures of files and when it couldn't validate them, it was failing. 

    I'm not sure about the other errors, but the full version of what I quoted should absolutely be the solution and someone at M$ needs their tail kicked for this failure.

  • I tried this as the entire fix on my SBS 2003 SP2 and it didn't change anything.

    I don't know where your quote came from though so there were probably steps I missed.

    Wednesday, June 13, 2012 8:23 PM
  • ...someone at M$ needs their tail kicked for this failure.


    Agree 100% - is the product group looking into this? Honestly the installer should be pulled until they can address the problem.
    Wednesday, June 13, 2012 8:27 PM
  • It came from further up the thread as part of a multi-step process. We tried it by itself and it didn't work for us either. Now going through all of the steps and verifying everything.
    Wednesday, June 13, 2012 8:42 PM
  • Not only that, they should issue a hot fix to clean up all this wreckage.
    Wednesday, June 13, 2012 8:44 PM
  • It came from further up the thread as part of a multi-step process. We tried it by itself and it didn't work for us either. Now going through all of the steps and verifying everything.

    Yes, I found it.  I'm running SBS 2003 though -- not 2008.  Also, I'm running the Windows SQL Desktop -- not SQL 2008.  Of course, it doesn't have an administration tool.  I'm trying to figure out if one of the express tools will work for me.

    I'd sure like to hear if you manage to get it working.

    Wednesday, June 13, 2012 8:46 PM
  • So far, no dice... we went through the four steps mentioned above and still DOA. At this point we are getting ready to engage MS Pro Support.
    Wednesday, June 13, 2012 10:42 PM
  • Hello all,

    I've installed KB2720211 on 5 Wsus (1 Upstream and 4 downstream in replica mode). Only one Wsus goes wrong.

    I've followed the method "Extract necessary files from 2720211 installer", setting the "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup\wYukonInstalled" to 0 (as suggest here http://msmvps.com/blogs/bradley/archive/2012/06/12/kb2720211-issues.aspx ) and reinstalling Kb2720211. This time the installation goes well. Setting back the registry key to 1. Restarting. Reinstalling the Kb2720211. Rebooting.

    The Wsus is up and running.

    Thanks all for all there informations.



    • Edited by DCourtel Thursday, June 14, 2012 1:56 PM
    Thursday, June 14, 2012 1:51 PM
  • Back again...

    Our WSUS is running again.

    Old rule: "In case of emergency you are on your own" - we were (beside the helpful hints in here...) !

    What we at the end did (on Windows 2003 R2 server - german) - using a wsus database from the day before the nice hotfix changed our mood (all steps were first tested in an vm and after we got a good result there, we did it on the "real" WSUS server):

    - uninstall .net components (all! - 3.5, 3.0, 2.0, .net Language Packs)

    - uninstall Report Viewer Redistriburtable (2008)

    - uninstall WSUS3SP2 (keep localy stored files - D:\WSUS)

    - uninstall "Internal Database"

    - uninstall IIS (WWW_Service)

    - deleted all folders that might be left from the uninstalled components (containing log-files, etc....)

    - install .net 2.0 + needed patches

    - install .net 3.5 sp1 + needed patches 

    - install IIS (needing the install cd for some files)

    - install WSUS3SP2 with

    -- install Internal Database

    -- to same place where old installation was (D:WSUS)

    - testing WSUS withe empty DB: opening the WSUS.msc - empty, but running

    - stopping related wsus services ("Update Services", "Windows Internal Database (MICROSOFT##SSEE)")

    - taking the last knwon good wsus database files ("SUSDB.mdf", "SUSDB_log.ldf") and putting them to the database file location of new installed WSUS ("D:\WSUS\UpdateServicesDbFiles")

    - to avoid old/empty parts of db in memory: reboot 

    - after reboot: check if database is okay - opening WSUS.msc ("C:\Programme\Update Services\administrationsnapin\wsus.msc") - running

    BUT: up to here not hotfixed WSUS3SP2 

    - patching after WSUS install (Internal Database SP4, WSUS3SP2 Hotfix, etc.) all in a row (no errors this time...)

    - reboot 

    - last test of hotfixed WSUS3SP2: "our" database worked

    -- a snyc worked and showed (for us) 240 new packages

    -- tcpview showed already conencted WSUS clients looking for new patches

    At the end the WSUS server is up and running 

    - the price: beside other things - one day late with the patches after patchday...

    Hope you will be able to come with your WSUS, too.

    Greetings from the north of Germany

    BSM

    P.S. bright spot: http://www.kieler-woche.de/english/index.php starting tomorrow - LIKE! :-)

    Thursday, June 14, 2012 2:32 PM
  • I had the same problems applying 2720211 on Windows 2003.  I didn't need to make the DCOM change, and I didn't reboot after changing the SUSDB to multiuser and enabling named pipes.  Otherwise - your instructions worked great!  Thanks for posting them.

    Thursday, June 14, 2012 3:08 PM
  • DCourtel said:

    Hello all,

    I've installed KB2720211 on 5 Wsus (1 Upstream and 4 downstream in replica mode). Only one Wsus goes wrong.

    I've followed the method "Extract necessary files from 2720211 installer", setting the "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup\wYukonInstalled" to 0 (as suggest here http://msmvps.com/blogs/bradley/archive/2012/06/12/kb2720211-issues.aspx ) and reinstalling Kb2720211. This time the installation goes well. Setting back the registry key to 1. Restarting. Reinstalling the Kb2720211. Rebooting.

    The Wsus is up and running.

    Thanks all for all there informations.



    That helped a great deal.  I have the thing installed and updates are being pushed out to clients.  However, WSUS still won't connect to the SUSDB.  I'm running SBS 2003 SP2 and Windows Internal Database and I don't find a way to look at the SUSDB SQL settings/permissions.  Is there any way to use SQL2005ExpressAdmin to do this on WID? I'd sure like to know the answer to that one.

    Thanks to all for the helpful information.

    Thursday, June 14, 2012 3:15 PM
  • I've installed SQL 2005 Express Admin but cannot connect to the SUSDB.

    (I'm in so far over my head.)

    Admin will connect to SBSMonitoring and SHAREPOINT but not to the WSUS database.

    I'm really lost here.

    AFAIK, KB2720211 really resembles MALWARE!

    My SUSDB.mdf and SUSDB_log.ldf are both there, still where I had put them, but I can't get connected.

    Really need some help here. 

    Thursday, June 14, 2012 5:49 PM
  • That's actually a normal error and not related to WSUS. 
    Thursday, June 14, 2012 11:22 PM
  • I successfully recovered WSUS without changing too much - hopefully this will work for others. The catch is you have to have a recent backup of your WSUS database.

    Step 1: Download the KB2720211 from Microsoft: http://support.microsoft.com/kb/2720211

    Step 2: Open Regedit, and change the value of this DWORD to 0: "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup\wYukonInstalled"

    Step 3: Install KB2720211

    Step 4: Change the DWORD value back to 1

    Step 5: Stop the SQL database service (I used Windows Internal Database, so it is MSSQL$MICROSOFT##SSEE)

    Step 6: Delete the DB files in *:\WSUS\UpdateServicesDbFiles (SUSDB.mdf & SUSDB_log.ldf)

    Step 7: Restore the SUSDB.mdf & SUSDB_log.ldf from backup

    Step 8: Start the SQL database service

    Step 9: Start the "Update Services" service

    At this point, WSUS should be functional again. I proceeded to run a synchronization and the cleanup wizard on it, but I believe at this point it is working properly.


    Friday, June 15, 2012 12:11 AM

    • Put the SUSDB database back into multi-user mode (might not be necessary, but I did it)

    1. Open a command prompt as administrator and run "iisreset /stop"
    2. Stop the "Update Services" service if running (it usually isn't since it's broken at this point)
    3. Open SQL Server Management Studio as Administrator (Start > Programs > Microsoft SQL Server 2008 R2)
    4. Under Server type, select "Database Engine", for server name, use "\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query", and for Authentication use "Windows Authentication". Click Connect.
    5. Look at your SUSDB (Databases > SUSDB). If it is in single-user mode, open its properties, go to the Options screen, and set the Restrict Access setting to "MULTI_USER". Let it reset connections if needed.
    6. Reboot your server (might not be necessary, but I figured it was best to play it safe)
    7. You might see a lot of MSSQL$MICROSOFT##SSEE event 33002 in the logs after the reboot, but you can ignore these for now since the patch "should" fix it in a bit.

    • Extract necessary files from 2720211 installer

    1. Download the KB2720211 installer for your architecture from Microsoft (http://support.microsoft.com/kb/2720211)
    2. Extract WUSSetup.msp from the installer by running the installer with the /extract parameter (example: "WSUS-KB2720211-x64.exe /extract")
    3. With 7-zip, open WUSSetup.msp and extract "PCW_CAB_SUS".
    4. With 7-zip, open "PCW_CAB_SUS" and extract "DbCert", "DbCertDll", and "DbCertSql".
    5. Rename those files to "WSUSSignDb.cer", "WSUSSignDb.dll", and "WSUSSignDb.sql", respectively.
    6. On your WSUS server, navigate to "C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\SchemaSig" and copy the extracted "WSUSSignDb.cer" and "WSUSSignDb.dll" to it. Make a backup copy of the two existing versions, just in case.
    7. On your WSUS server, navigate to "C:\Program Files\Update Services\Database" and copy the extracted "WSUSSignDb.sql" to it. Make a backup copy of any existing versions of the file.

    At this point, you should (cross your fingers!) be able to try reinstalling the 2720211 patch and see if it finishes. If it does, your WSUS should be back to normal. I realize that this was a lot of steps, but this is what I did to get my server up and running again. I hope it works for you!

    Thank you very much. I've been beating my head against this all morning! Clear, concise instructions.

    Resolved just 20mins before i leave the office for the weekend. I didn't want to have to come back in on monday and keep searching for a solution. So thanks for the steps.


    • Edited by Dishco Friday, June 15, 2012 11:42 AM
    Friday, June 15, 2012 11:42 AM
  • well, like everyone else I encountered this. I was trying to get it up so I could migrate it. This was on Server2003 with the embedded database.

    initial status:

    Update installed via WSUS update and system rebooted. Permission errors for database. Console can't connect.

    My Fix based on some forum posts from other wsus issues was to...

    D/L offline 2720211 installer
    change HKEY_LOCAL_MACHINE\Software\Microsoft\Update Services\Server\Setup\wYukonInstalled from 1 to 0
    install update again
    reboot
    change HKEY_LOCAL_MACHINE\Software\Microsoft\Update Services\Server\Setup\wYukonInstalled from 0 to 1
    reboot
    install update AGAIN

    Friday, June 15, 2012 2:52 PM
  • Thanks chucker2.

    Extracting those files fixed it up for me. Having the detailed steps was a great help.


    Byron Wright (http://byronwright.blogspot.com)


    Friday, June 15, 2012 9:50 PM
  • I successfully recovered WSUS without changing too much - hopefully this will work for others. The catch is you have to have a recent backup of your WSUS database.

    Step 1: Download the KB2720211 from Microsoft: http://support.microsoft.com/kb/2720211

    Step 2: Open Regedit, and change the value of this DWORD to 0: "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup\wYukonInstalled"

    Step 3: Install KB2720211

    Step 4: Change the DWORD value back to 1

    Step 5: Stop the SQL database service (I used Windows Internal Database, so it is MSSQL$MICROSOFT##SSEE)

    Step 6: Delete the DB files in *:\WSUS\UpdateServicesDbFiles (SUSDB.mdf & SUSDB_log.ldf)

    Step 7: Restore the SUSDB.mdf & SUSDB_log.ldf from backup

    Step 8: Start the SQL database service

    Step 9: Start the "Update Services" service

    At this point, WSUS should be functional again. I proceeded to run a synchronization and the cleanup wizard on it, but I believe at this point it is working properly.


    Thanks. Very helpful!
    Saturday, June 16, 2012 9:24 AM
  • Okay. I managed to get my WSUS install running again, with a set of very complicated steps. While I have done a few other things trying to make this work, I believe these are the more "generic" steps.

    • Fix the DCOM issue (thanks Ickis99) - Check for DistributedCOM event 10016 in the System Event log for APPID {B292921D-AF50-400C-9B75-0C57A7F29BA1}

    1. If you have Windows Server 2008 R2, you have to give yourself permission to change the settings of the Component Service by looking for the APPID in the windows Registy under HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID. Then change the permissions of the Key by taking ownership of the object and give Full Permissions to the local Administrator-Group. After that you can change the DCOM Permissions in the Component Services.
    2. Open Administrative Tools > Component Services
    3. Within Component Services, open Computers > My Computer > DCOM Config
    4. Find the NAP Agent Service, right-click it, and open Properties.
    5. Under the security tab, hit "Edit..." under the Launch and Activation Permissions section.
    6. Give the SYSTEM user allow for Local Launch.

    • Enable Named Pipes for the local SQL Server Express install - Check for MSSQL$MICROSOFT##SSEE event 18456 in the Application event log

    1. Open the Sql Server Configuration Manager (Start > Programs > Microsoft SQL Server 2008 R2 > Configuration Tools)
    2. SQL Server Network Configuration  > Protocols for MICROSOFT##SSEE
    3. Open Properties for Named Pipes and set Enabled to Yes.

    • Put the SUSDB database back into multi-user mode (might not be necessary, but I did it)

    1. Open a command prompt as administrator and run "iisreset /stop"
    2. Stop the "Update Services" service if running (it usually isn't since it's broken at this point)
    3. Open SQL Server Management Studio as Administrator (Start > Programs > Microsoft SQL Server 2008 R2)
    4. Under Server type, select "Database Engine", for server name, use "\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query", and for Authentication use "Windows Authentication". Click Connect.
    5. Look at your SUSDB (Databases > SUSDB). If it is in single-user mode, open its properties, go to the Options screen, and set the Restrict Access setting to "MULTI_USER". Let it reset connections if needed.
    6. Reboot your server (might not be necessary, but I figured it was best to play it safe)
    7. You might see a lot of MSSQL$MICROSOFT##SSEE event 33002 in the logs after the reboot, but you can ignore these for now since the patch "should" fix it in a bit.

    • Extract necessary files from 2720211 installer

    1. Download the KB2720211 installer for your architecture from Microsoft (http://support.microsoft.com/kb/2720211)
    2. Extract WUSSetup.msp from the installer by running the installer with the /extract parameter (example: "WSUS-KB2720211-x64.exe /extract")
    3. With 7-zip, open WUSSetup.msp and extract "PCW_CAB_SUS".
    4. With 7-zip, open "PCW_CAB_SUS" and extract "DbCert", "DbCertDll", and "DbCertSql".
    5. Rename those files to "WSUSSignDb.cer", "WSUSSignDb.dll", and "WSUSSignDb.sql", respectively.
    6. On your WSUS server, navigate to "C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\SchemaSig" and copy the extracted "WSUSSignDb.cer" and "WSUSSignDb.dll" to it. Make a backup copy of the two existing versions, just in case.
    7. On your WSUS server, navigate to "C:\Program Files\Update Services\Database" and copy the extracted "WSUSSignDb.sql" to it. Make a backup copy of any existing versions of the file.

    At this point, you should (cross your fingers!) be able to try reinstalling the 2720211 patch and see if it finishes. If it does, your WSUS should be back to normal. I realize that this was a lot of steps, but this is what I did to get my server up and running again. I hope it works for you!




    These steps verbatim worked for me without any reboots.

    
    • Edited by Codewize Sunday, June 17, 2012 6:00 AM
    • Proposed as answer by flying38 Monday, June 18, 2012 9:27 AM
    • Unproposed as answer by flying38 Monday, June 18, 2012 9:27 AM
    Sunday, June 17, 2012 5:59 AM
  • Hi,

    exactly same stuff on my Environment. Uninstalled, reinstalled all things done. Now only i install this and it works: http://support.microsoft.com/kb/2720211

    Funny!

    Tuesday, June 19, 2012 1:41 PM
  • Great instructions, thanks!

    Unfortunately, I had one further problem. I am using standalone MS SQL 2005. After following you instructions above there was an error about a process didn't finish correctly. So, I had a look at the log and after searching for "error" found this many rows down:

    Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not

    finish as expected. Contact your support personnel or package vendor. Action ExConfigureDb, location:

    C:\WINDOWS\Installer\MSI1F5.tmp, command: -S SERVER -F SUSDB -i

    "C:\Program Files\Update Services\Database\CreateDatabase.sql;[...ManyOther .sql Files ...];

    C:\Program Files\Update Services\Database\PublicViews.sql" -l "C:\DOCUME~1\user\LOCALS~1\Temp\MWusCa.log"

    MWusCa.log was much shorter and had this at the bottom:

    tbDeployment exists, updating it

    Msg 8649, Level 17, State 1, Server SERVER, Line 45

    The query has been canceled because the estimated cost of this query (343) exceeds the configured

    threshold of 300. Contact the system administrator.Msg 3621, Level 0, State 0, Server SERVER, Line 1

    The statement has been terminated.


    So, into SQL management studio I went and found/changed the setting (I raised the limit from 300 to 500):

    Server Properties, Connections page

    After making this change, the update applied successfully; I restarted IIS and WSUS console is now working. No reboots required!


    • Edited by JGurtz Tuesday, June 19, 2012 2:56 PM
    Tuesday, June 19, 2012 2:36 PM
  • WSUS 3.0 SP2 will not run after installing update 2720211

    Great Stuff, I only needed to do the last step by placing the extracted files and then run the installer again and it all worked fine.

    • Extract necessary files from 2720211 installer

    1. Download the KB2720211 installer for your architecture from Microsoft (http://support.microsoft.com/kb/2720211)
    2. Extract WUSSetup.msp from the installer by running the installer with the /extract parameter (example: "WSUS-KB2720211-x64.exe /extract")
    3. With 7-zip, open WUSSetup.msp and extract "PCW_CAB_SUS".
    4. With 7-zip, open "PCW_CAB_SUS" and extract "DbCert", "DbCertDll", and "DbCertSql".
    5. Rename those files to "WSUSSignDb.cer", "WSUSSignDb.dll", and "WSUSSignDb.sql", respectively.
    6. On your WSUS server, navigate to "C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\SchemaSig" and copy the extracted "WSUSSignDb.cer" and "WSUSSignDb.dll" to it. Make a backup copy of the two existing versions, just in case.
    7. On your WSUS server, navigate to "C:\Program Files\Update Services\Database" and copy the extracted "WSUSSignDb.sql" to it. Make a backup copy of any existing versions of the file.

    First few steps didn't apply to me.

    Many Thanks

    • Proposed as answer by sgcadmin Monday, July 02, 2012 5:26 AM
    • Unproposed as answer by sgcadmin Monday, July 02, 2012 5:26 AM
    Wednesday, June 20, 2012 1:00 PM
  • I have tried everything mention on this post with no luck.  WSUS is still down.  We are using SQL 2008 as the database for WSUS and SCCM 2007 on the same server, and notice the following step only apply to SQL express:

    6.  On your WSUS server, navigate to "C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\SchemaSig" and copy the extracted "WSUSSignDB.cer" and "WSUSSignDb.dll" to it.

    With SQL 2008 we do not have the directories mention above.  At this point, I think our WSUS is FUBR and will probably need to re-install.  Anybody have other suggested fix for this?  Many thanks in advance for the help.


    • Edited by KidDragon Thursday, June 21, 2012 11:16 AM
    Thursday, June 21, 2012 10:54 AM
  • Our WSUS is installed on a WIN2K8 box and the WSUSDB is located on a remote SQL 2008 server and sure enough KB2720211 broke the WSUS console. After reading KB2720211 it states under Known Issues:

    "Remote Microsoft SQL Server administrators must download and install the update by using an account that has SQL server administrator permissions. Remote SQL server installation will always require manual installation."  I knew I had my answer. I was using a local admin account on the WSUS server which had no perms to the remote DB server.

    What amazes me is why release this as a WSUS update since know its going to break "WSUS on remote SQL installs" if done automatically via WSUS..no?

    So here is what we did:

    I had a Domain admin (whose account is server Admin on WSUSDB ) download and install KB2720211 manually using his DA account.

    Once installation was completed ans server was rebooted WSUS worked and all looks good. FWIW - before we started the manual install,  I looked at the reg key "HKLM\software\microsoft\update Services\Server\Setup\wYukonInstalled" mentioned on various sites and part of many suggested solutions and the key was set to '0' before install and has stayed at '0' after install. I did not modify anything.


    • Edited by Futuresdc Thursday, June 21, 2012 2:12 PM clarification
    Thursday, June 21, 2012 2:10 PM
  • well, like everyone else I encountered this. I was trying to get it up so I could migrate it. This was on Server2003 with the embedded database.

    initial status:

    Update installed via WSUS update and system rebooted. Permission errors for database. Console can't connect.

    My Fix based on some forum posts from other wsus issues was to...

    D/L offline 2720211 installer
    change HKEY_LOCAL_MACHINE\Software\Microsoft\Update Services\Server\Setup\wYukonInstalled from 1 to 0
    install update again
    reboot
    change HKEY_LOCAL_MACHINE\Software\Microsoft\Update Services\Server\Setup\wYukonInstalled from 0 to 1
    reboot
    install update AGAIN

    This fixed it for me. Same OS, same problems.
    Thursday, June 21, 2012 3:43 PM
  • WSUS KB2720211 : Common issues encountered and how to fix them - The WSUS Support Team Blog - Site Home - TechNet Blogs:
    http://blogs.technet.com/b/sus/archive/2012/06/20/wsus-kb272011-common-issues-encountered-and-how-to-fix-them.aspx

    (And I'm not sure who flagged this post as abusive, but as a person who's trying to get the WSUS team to acknowledge issues with this update, it's not appreciated one bit.  All I'm trying to do with this post is help people and for someone to flag it as abusive is hurtful to me.  The reason I posted it was to at least show that the WSUS team is aware of it.  Given that commenting on the blog post is typically the best way to get feedback to the team, go pile on the comments there rather than flagging my post of merely the blog url as abusive.

    I didn't code the patch.  I'm just trying to get to the bottom of the issue.)

    Friday, June 22, 2012 5:15 PM
  • Thanks chucker2! Worked for us on 2003 Std SP2. Though we weren't seeing the DCOM errors.
    Friday, June 22, 2012 5:32 PM
  • Great, but it looks like they haven't noticed all the issues reported in this thread.

    Specifically: The update did not extract files to the right places and failed; after this failure it did not roll-back completely leaving the SUSDB in single user mode and the application in a bad state. As a result, WSUS becomes completely non-functional (no sync, no user access, no management console). Restoration is as easy as manual extraction of certificate and related files using a 3rd-party tool and running the update manually.

    It's hard for me to see this issue as not being specifically caused by the patch since WSUS was working just fine and without error prior to the patch application.

    Friday, June 22, 2012 5:50 PM
  • This page helped alot. Let me recap for others on the interwebs.

    Cause:

    - Applied KB2720211 to a WSUS 3.0 SP2 server thats running on Windows 2008 64 bit server with local SQL db.

    What happened:

    - I could no longer sync my WSUS server with the interwebs.
    - clients could still connect to WSUS and I could still open the WSUS console.
    - Uninstalled WSUS, left DB and downloads and reinstalled WSUS in attempt to fix broken syncing.
    - Clients could now no longer sync with WSUS server. (They got Windows Update error code 800B0001).

    Solution:

    - Googled, found this page.
    - Followed just these last few steps that Chucker2 posted.

    • Extract necessary files from 2720211 installer

    1. Download the KB2720211 installer for your architecture from Microsoft (http://support.microsoft.com/kb/2720211)
    2. Extract WUSSetup.msp from the installer by running the installer with the /extract parameter (example: "WSUS-KB2720211-x64.exe /extract")
    3. With 7-zip, open WUSSetup.msp and extract "PCW_CAB_SUS".
    4. With 7-zip, open "PCW_CAB_SUS" and extract "DbCert", "DbCertDll", and "DbCertSql".
    5. Rename those files to "WSUSSignDb.cer", "WSUSSignDb.dll", and "WSUSSignDb.sql", respectively.
    6. On your WSUS server, navigate to "C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\SchemaSig" and copy the extracted "WSUSSignDb.cer" and "WSUSSignDb.dll" to it. Make a backup copy of the two existing versions, just in case.
    7. On your WSUS server, navigate to "C:\Program Files\Update Services\Database" and copy the extracted "WSUSSignDb.sql" to it. Make a backup copy of any existing versions of the file.
    8. Reinstalled 2720211

    PROBLEM FIXED AND CLIENTS COULD ALL SYNCH AGAIN.

    Thanks Chucker 2.

    ps. Susan Bradley stop polluting every WSUS post on the interwebs with your constant links to WSUS KB2720211 : Common issues encountered and how to fix them

    • Proposed as answer by t kailash Monday, July 02, 2012 7:28 AM
    Wednesday, June 27, 2012 7:15 AM
  • Sorry, I don't consider it polluting, it's trying to post another resource on a forum.
    Wednesday, June 27, 2012 7:22 AM
  • P.S. I'd comment on that blog post as comments go back to the product team and are prob the best way to get feedback back to them.
    Wednesday, June 27, 2012 7:23 AM
  • An additional step required by my server (Windows 2003 standard box) was to alter the permissions of C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\SchemaSig (assuming you're using the integrated DB option) as in my situation either some other user or the NETWORK SERVICE account could not access the certificate in that folder.  In my case, I just opened the folder up to Everyone, but simply adding read access to NETWORK SERVICE or whatever service account the SQL service is running under may be enough.

    Once the permissions were changed in addition to chucker2's other steps, my installation of the hotfix finally completed and WSUS returned to a running state.


    Thursday, June 28, 2012 9:12 PM
  • Same for me as well.  Using 7zip to extract and replace those 3 files fixed it after a reboot of the system.

    Thanks!

    Monday, July 02, 2012 5:27 AM
  • This page helped alot. Let me recap for others on the interwebs.

    Cause:

    - Applied KB2720211 to a WSUS 3.0 SP2 server thats running on Windows 2008 64 bit server with local SQL db.

    What happened:

    - I could no longer sync my WSUS server with the interwebs.
    - clients could still connect to WSUS and I could still open the WSUS console.
    - Uninstalled WSUS, left DB and downloads and reinstalled WSUS in attempt to fix broken syncing.
    - Clients could now no longer sync with WSUS server. (They got Windows Update error code 800B0001).

    Solution:

    - Googled, found this page.
    - Followed just these last few steps that Chucker2 posted.

    • Extract necessary files from 2720211 installer

    1. Download the KB2720211 installer for your architecture from Microsoft (http://support.microsoft.com/kb/2720211)
    2. Extract WUSSetup.msp from the installer by running the installer with the /extract parameter (example: "WSUS-KB2720211-x64.exe /extract")
    3. With 7-zip, open WUSSetup.msp and extract "PCW_CAB_SUS".
    4. With 7-zip, open "PCW_CAB_SUS" and extract "DbCert", "DbCertDll", and "DbCertSql".
    5. Rename those files to "WSUSSignDb.cer", "WSUSSignDb.dll", and "WSUSSignDb.sql", respectively.
    6. On your WSUS server, navigate to "C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\SchemaSig" and copy the extracted "WSUSSignDb.cer" and "WSUSSignDb.dll" to it. Make a backup copy of the two existing versions, just in case.
    7. On your WSUS server, navigate to "C:\Program Files\Update Services\Database" and copy the extracted "WSUSSignDb.sql" to it. Make a backup copy of any existing versions of the file.
    8. Reinstalled 2720211

    PROBLEM FIXED AND CLIENTS COULD ALL SYNCH AGAIN.

    Thanks Chucker 2.

    ps. Susan Bradley stop polluting every WSUS post on the interwebs with your constant links to WSUS KB2720211 : Common issues encountered and how to fix them


    this is the best solution. after reboot the problem is solved .

    kailash

    Monday, July 02, 2012 7:29 AM
  • I've tried all of the instructions recommended by Chucker with no success.  The trick is that there is another SQL DB that is failing as a result that is tied to the enterprise anti-virus (VIPRE).  So, not sure uninstalling/re-installing WSUS and then running through the process is the easiest thing to do, unless I'm ready to reinstall VIPRE enterprise from scratch which could create licensing issues....
    Monday, July 02, 2012 5:53 PM
  • Call 1-800-Microsoft.  State you have an issue post 2720211 install and you require free support (which they have been giving)
    Monday, July 02, 2012 5:58 PM
  • Additionally,

    The directory:  "C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\SchemaSig" does not exist on the server I am working on (2003 Standard R2 SP2).

    Monday, July 02, 2012 6:04 PM
  • Okay. I managed to get my WSUS install running again, with a set of very complicated steps. While I have done a few other things trying to make this work, I believe these are the more "generic" steps.

    • Fix the DCOM issue (thanks Ickis99) - Check for DistributedCOM event 10016 in the System Event log for APPID {B292921D-AF50-400C-9B75-0C57A7F29BA1}

    If you have Windows Server 2008 R2, you have to give yourself permission to change the settings of the Component Service by looking for the APPID in the windows Registy under HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID. Then change the permissions of the Key by taking ownership of the object and give Full Permissions to the local Administrator-Group. After that you can change the DCOM Permissions in the Component Services.

    1. Open Administrative Tools > Component Services
    2. Within Component Services, open Computers > My Computer > DCOM Config
    3. Find the NAP Agent Service, right-click it, and open Properties.
    4. Under the security tab, hit "Edit..." under the Launch and Activation Permissions section.
    5. Give the SYSTEM user allow for Local Launch.

    • Enable Named Pipes for the local SQL Server Express install - Check for MSSQL$MICROSOFT##SSEE event 18456 in the Application event log

    Open the Sql Server Configuration Manager (Start > Programs > Microsoft SQL Server 2008 R2 > Configuration Tools)

    1. SQL Server Network Configuration  > Protocols for MICROSOFT##SSEE
    2. Open Properties for Named Pipes and set Enabled to Yes.

    Put the SUSDB database back into multi-user mode (might not be necessary, but I did it)

    Open a command prompt as administrator and run "iisreset /stop"

    1. Stop the "Update Services" service if running (it usually isn't since it's broken at this point)
    2. Open SQL Server Management Studio as Administrator (Start > Programs > Microsoft SQL Server 2008 R2)
    3. Under Server type, select "Database Engine", for server name, use "\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query", and for Authentication use "Windows Authentication". Click Connect.
    4. Look at your SUSDB (Databases > SUSDB). If it is in single-user mode, open its properties, go to the Options screen, and set the Restrict Access setting to "MULTI_USER". Let it reset connections if needed.
    5. Reboot your server (might not be necessary, but I figured it was best to play it safe)
    6. You might see a lot of MSSQL$MICROSOFT##SSEE event 33002 in the logs after the reboot, but you can ignore these for now since the patch "should" fix it in a bit.

    • Extract necessary files from 2720211 installer

    Download the KB2720211 installer for your architecture from Microsoft (http://support.microsoft.com/kb/2720211)

    1. Extract WUSSetup.msp from the installer by running the installer with the /extract parameter (example: "WSUS-KB2720211-x64.exe /extract")
    2. With 7-zip, open WUSSetup.msp and extract "PCW_CAB_SUS".
    3. With 7-zip, open "PCW_CAB_SUS" and extract "DbCert", "DbCertDll", and "DbCertSql".
    4. Rename those files to "WSUSSignDb.cer", "WSUSSignDb.dll", and "WSUSSignDb.sql", respectively.
    5. On your WSUS server, navigate to "C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\SchemaSig" and copy the extracted "WSUSSignDb.cer" and "WSUSSignDb.dll" to it. Make a backup copy of the two existing versions, just in case.
    6. On your WSUS server, navigate to "C:\Program Files\Update Services\Database" and copy the extracted "WSUSSignDb.sql" to it. Make a backup copy of any existing versions of the file.

    At this point, you should (cross your fingers!) be able to try reinstalling the 2720211 patch and see if it finishes. If it does, your WSUS should be back to normal. I realize that this was a lot of steps, but this is what I did to get my server up and running again. I hope it works for you!

    I found chucker2 steps helpfull.

    Fixed DCOM error. We used sql 2005 internal database. Enabled named pipes as suggeseted, but skipped section 'Put the SUSDB database back into multi-user mode'

    Note: in third section, 'Extract necessary files from 2720211' step 6, I also had to place the extracted/renamed file, 'WSUSSignDb.sql' into the same folder, C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\SchemaSig.

    Andrew.


    Thanks, Andrew

    Friday, July 06, 2012 6:24 AM
  • I use this procedure

    xtract necessary files from 2720211 installer

    Download the KB2720211 installer for your architecture from Microsoft (http://support.microsoft.com/kb/2720211)

    1. Extract WUSSetup.msp from the installer by running the installer with the /extract parameter (example: "WSUS-KB2720211-x64.exe /extract")
    2. With 7-zip, open WUSSetup.msp and extract "PCW_CAB_SUS".
    3. With 7-zip, open "PCW_CAB_SUS" and extract "DbCert", "DbCertDll", and "DbCertSql".
    4. Rename those files to "WSUSSignDb.cer", "WSUSSignDb.dll", and "WSUSSignDb.sql", respectively.
    5. On your WSUS server, navigate to "C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\SchemaSig" and copy the extracted "WSUSSignDb.cer" and "WSUSSignDb.dll" to it. Make a backup copy of the two existing versions, just in case.
    6. On your WSUS server, navigate to "C:\Program Files\Update Services\Database" and copy the extracted "WSUSSignDb.sql" to it. Make a backup copy of any existing versions of the file.

    At this point, you should (cross your fingers!) be able to try reinstalling the 2720211 patch and see if it finishes. If it does, your WSUS should be back to normal. I realize that this was a lot of steps, but this is what I did to get my server up and running again. I hope it works for you!add

    adding this steps:

    I've installed KB2720211 on 5 Wsus (1 Upstream and 4 downstream in replica mode). Only one Wsus goes wrong.
    I've followed the method "Extract necessary files from 2720211 installer", setting the "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup\wYukonInstalled" to 0 (as suggest here http://msmvps.com/blogs/bradley/archive/2012/06/12/kb2720211-issues.aspx ) and reinstalling Kb2720211. This time the installation goes well. Setting back the registry key to 1. Restarting. Reinstalling the Kb2720211. Rebooting.
    The Wsus is up and running

    my wsus server again !!!!!!!

    Saturday, July 07, 2012 11:39 PM
  • Interesting stories.. and methodologies.

    On Friday I installed KB2720211, from the command line, on four WSUS servers, and a dozen other systems running a WSUS console installation.

    One WSUS server had an issue because I arrogantly ignored the pre-setup recommendations -- I didn't run the Server Cleanup Wizard. Fact is, I had been ignoring the WSUS server for some time, and I knew that, and as it turned out, the volume with the content store was out of disk space. Cleaned up the disk space issue, took the database back out of single-user mode (where the update inappropriately left it), and the update installed fine.

    The other machine I had an issue with was a Win2003 x86 machine -- but it was a VM with some snapshot integrity issues, and I think it was a lost cause before I ever tried. I'm reinstalling the OS on that machine today. (It's a reference machine for answering WSUS on Win2003 questions that still come up a LOT.) But maybe not -- as from what I've read, the majority of the update issues have been on '2003' machines.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Product Manager, SolarWinds
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    Sunday, July 08, 2012 2:24 PM
    Moderator
  • Our WSUS is installed on a WIN2K8 box and the WSUSDB is located on a remote SQL 2008 server and sure enough KB2720211 broke the WSUS console. After reading KB2720211 it states under Known Issues:

    "Remote Microsoft SQL Server administrators must download and install the update by using an account that has SQL server administrator permissions. Remote SQL server installation will always require manual installation."  I knew I had my answer. I was using a local admin account on the WSUS server which had no perms to the remote DB server.

    What amazes me is why release this as a WSUS update since know its going to break "WSUS on remote SQL installs" if done automatically via WSUS..no?

    So here is what we did:

    I had a Domain admin (whose account is server Admin on WSUSDB ) download and install KB2720211 manually using his DA account.

    Once installation was completed ans server was rebooted WSUS worked and all looks good. FWIW - before we started the manual install,  I looked at the reg key "HKLM\software\microsoft\update Services\Server\Setup\wYukonInstalled" mentioned on various sites and part of many suggested solutions and the key was set to '0' before install and has stayed at '0' after install. I did not modify anything.


    I tried installing this patch on my 2008 SP2 Server with a remote SQL DB on a SQL 2008 R2 server. I installed with a DA account with local admin rights on both boxes. The install failed, with very similar issues in this thread. I have gone back and given the DA account and the local server acount DBO rights on the SUSDB and tried again with no luck. I have tried everything else in this thread with no luck. The only step I didnt not try as I was unable to was the same result at KIDDRAGON I dont have the "C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\SchemaSig directory to put the extracted files in. Has anyone put the extracted files on a remote SQL 2008 server? I am guessing there is a different directory for the files but I have yet to find it. My WSUS Server is still down and need to find a fix.
    Wednesday, July 18, 2012 6:13 PM
  • Our WSUS is installed on a WIN2K8 box and the WSUSDB is located on a remote SQL 2008 server and sure enough KB2720211 broke the WSUS console. After reading KB2720211 it states under Known Issues:

    "Remote Microsoft SQL Server administrators must download and install the update by using an account that has SQL server administrator permissions. Remote SQL server installation will always require manual installation."  I knew I had my answer. I was using a local admin account on the WSUS server which had no perms to the remote DB server.

    What amazes me is why release this as a WSUS update since know its going to break "WSUS on remote SQL installs" if done automatically via WSUS..no?

    So here is what we did:

    I had a Domain admin (whose account is server Admin on WSUSDB ) download and install KB2720211 manually using his DA account.

    Once installation was completed ans server was rebooted WSUS worked and all looks good. FWIW - before we started the manual install,  I looked at the reg key "HKLM\software\microsoft\update Services\Server\Setup\wYukonInstalled" mentioned on various sites and part of many suggested solutions and the key was set to '0' before install and has stayed at '0' after install. I did not modify anything.


    I tried installing this patch on my 2008 SP2 Server with a remote SQL DB on a SQL 2008 R2 server. I installed with a DA account with local admin rights on both boxes. The install failed, with very similar issues in this thread. I have gone back and given the DA account and the local server acount DBO rights on the SUSDB and tried again with no luck. I have tried everything else in this thread with no luck. The only step I didnt not try as I was unable to was the same result at KIDDRAGON I dont have the "C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\SchemaSig directory to put the extracted files in. Has anyone put the extracted files on a remote SQL 2008 server? I am guessing there is a different directory for the files but I have yet to find it. My WSUS Server is still down and need to find a fix.

    In my case I found that when WSUS installed the DB on the remote server it only gave the server itself access to the database. When the update ran it failed as the user account that was running the udpate did not have access to the database. Once the patched failed my console broke. Since my WSUS is virtual I rolled back the VM to before I ran the patch and also restored my database on the remote SQL box. I then had a working console again. Once that was done I gave the account I was using to run the update DBO rights on the database and the patch installed with out any issue. The KB should have been a bit more clear on why it was saying to have your
    Monday, July 23, 2012 8:12 PM
  • In my case I found that when WSUS installed the DB on the remote server it only gave the server itself access to the database. When the update ran it failed as the user account that was running the udpate did not have access to the database.

    It is unfortunate that the KB article (or some other related document) did not discuss these finer points;  however, the requirement for the install user to have database permissions applied to the original installation to the remote SQL server, and could be reasonably expected to apply to any subsequent updates.

    Even more unfortunate is that the core documentation for using a remote SQL server was "lost" in last year's re-write of the WSUS documentation. You can find the original WSUS3SP2 Deployment Guide Appendix B at http://technet.microsoft.com/en-us/library/dd939912(v=WS.10).aspx.

    Appendix B: Configure Remote SQL

    WSUS offers limited support for running database software on a computer that is separate from the computer where the rest of WSUS is installed. This section offers step-by-step instructions for how to install WSUS in this configuration.

    Setting up WSUS for remote SQL is a three-step process:

    1. Install and configure Microsoft SQL Server 2008 Standard or Enterprise Edition or Microsoft SQL Server 2005 SP3 or later versions on the back-end server.
    2. Confirm that the administrator who is going to install WSUS 3.0 SP2 also has permissions on SQL Server.
    3. Install WSUS 3.0 SP2 on the front-end computer, and configure it to use the database on the back-end computer.

    Of course, even that document would have only been partially helpful as a less-than-visionary statement at the end advises that the account can be deleted after the installation is complete. (Which would, then, no doubt, need to be RE-created in order to install any subsequent updates -- like KB2720211.)

    Also still available, but much less intuitive a place to look, the original Appendix B is still available in the WSUS v3 SP1 Deployment Guide. 


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Product Manager, SolarWinds
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    Monday, July 23, 2012 10:02 PM
    Moderator
  • Okay. I managed to get my WSUS install running again, with a set of very complicated steps. While I have done a few other things trying to make this work, I believe these are the more "generic" steps.

    • Fix the DCOM issue (thanks Ickis99) - Check for DistributedCOM event 10016 in the System Event log for APPID {B292921D-AF50-400C-9B75-0C57A7F29BA1}

    1. If you have Windows Server 2008 R2, you have to give yourself permission to change the settings of the Component Service by looking for the APPID in the windows Registy under HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID. Then change the permissions of the Key by taking ownership of the object and give Full Permissions to the local Administrator-Group. After that you can change the DCOM Permissions in the Component Services.
    2. Open Administrative Tools > Component Services
    3. Within Component Services, open Computers > My Computer > DCOM Config
    4. Find the NAP Agent Service, right-click it, and open Properties.
    5. Under the security tab, hit "Edit..." under the Launch and Activation Permissions section.
    6. Give the SYSTEM user allow for Local Launch.

    • Enable Named Pipes for the local SQL Server Express install - Check for MSSQL$MICROSOFT##SSEE event 18456 in the Application event log

    1. Open the Sql Server Configuration Manager (Start > Programs > Microsoft SQL Server 2008 R2 > Configuration Tools)
    2. SQL Server Network Configuration  > Protocols for MICROSOFT##SSEE
    3. Open Properties for Named Pipes and set Enabled to Yes.

    • Put the SUSDB database back into multi-user mode (might not be necessary, but I did it)

    1. Open a command prompt as administrator and run "iisreset /stop"
    2. Stop the "Update Services" service if running (it usually isn't since it's broken at this point)
    3. Open SQL Server Management Studio as Administrator (Start > Programs > Microsoft SQL Server 2008 R2)
    4. Under Server type, select "Database Engine", for server name, use "\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query", and for Authentication use "Windows Authentication". Click Connect.
    5. Look at your SUSDB (Databases > SUSDB). If it is in single-user mode, open its properties, go to the Options screen, and set the Restrict Access setting to "MULTI_USER". Let it reset connections if needed.
    6. Reboot your server (might not be necessary, but I figured it was best to play it safe)
    7. You might see a lot of MSSQL$MICROSOFT##SSEE event 33002 in the logs after the reboot, but you can ignore these for now since the patch "should" fix it in a bit.

    • Extract necessary files from 2720211 installer

    1. Download the KB2720211 installer for your architecture from Microsoft (http://support.microsoft.com/kb/2720211)
    2. Extract WUSSetup.msp from the installer by running the installer with the /extract parameter (example: "WSUS-KB2720211-x64.exe /extract")
    3. With 7-zip, open WUSSetup.msp and extract "PCW_CAB_SUS".
    4. With 7-zip, open "PCW_CAB_SUS" and extract "DbCert", "DbCertDll", and "DbCertSql".
    5. Rename those files to "WSUSSignDb.cer", "WSUSSignDb.dll", and "WSUSSignDb.sql", respectively.
    6. On your WSUS server, navigate to "C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\SchemaSig" and copy the extracted "WSUSSignDb.cer" and "WSUSSignDb.dll" to it. Make a backup copy of the two existing versions, just in case.
    7. On your WSUS server, navigate to "C:\Program Files\Update Services\Database" and copy the extracted "WSUSSignDb.sql" to it. Make a backup copy of any existing versions of the file.

    At this point, you should (cross your fingers!) be able to try reinstalling the 2720211 patch and see if it finishes. If it does, your WSUS should be back to normal. I realize that this was a lot of steps, but this is what I did to get my server up and running again. I hope it works for you!






    Thank you for this chucker2, worked a treat for me. You've got to hand it to Microsoft they really know how to give you a headache! I agree with MajikUF, the developement team need their collective asses kicked for this one.

    Wednesday, August 01, 2012 12:40 PM
  • Put the SUSDB database back into multi-user mode (might not be necessary, but I did it)

    It is worthy of note here that if the database is in single-user mode, it *MUST* be placed back into multi-user mode, and the fact that it's not in multi-user mode is the most likely single root-cause for the WSUS server's failure to operate.

    I would recommend stopping the Update Services service, put the database back in multi-user mode, restart the Update Services service, and test the WSUS server again before taking any other remediation actions. If the 'fix' is as simple as restoring normal functionality to the database --- that seems to me to be the best move.

    If the service restarts .. then retry KB2720211.

    Btw, I did not find it necessary to extract anything from the update package, I just re-ran the whole package from the command line. (Actually, truth be told, I double-clicked on it in Windows Explorer.)


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Product Manager, SolarWinds
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    Wednesday, August 01, 2012 5:26 PM
    Moderator
  • Hey Guys - had a helluva time with this update.  The update continued to fail, then WSUS wouldn't start.  ALL because of access to the remote DB.

    very long story - short fix.

    Make sure you have full admin access to the remote DB/DBO, re-run the KB patch

    All of the other WSUS problems disappeared for me, once I got the patch to install correctly.  Despite the condition of the DB the patch corrected everything with a successful install.

    • Proposed as answer by erpede Thursday, September 20, 2012 2:08 PM
    Thursday, August 09, 2012 10:04 AM
  • This instruction set worked for me!  Your connect string was extremely helpful in just getting attached!  Thank you! 

    We discovered the Network Service was not listed as a User of the DB, once we were able to connect, we also seemed to have lost File level rights to the file. 

    Very painful update, and esoteric enough that the issue was not recognized for almost a full week in our environment! 

    Thanks again!

    Thursday, August 09, 2012 7:09 PM
  • Chucker2,

    A bit convoluted; But it worked. Your solution/skill in this matter is much appreciated!

    -Cheers

    Xerxes


    • Edited by Theace Sunday, August 12, 2012 1:09 AM
    Sunday, August 12, 2012 1:03 AM
  • This worked for us.

    Thanks, Lawrence.

    Friday, August 17, 2012 9:55 PM
  • I hope this helps someone else fix this problem.  None of the above solutions worked for one reason or another.  Here is the situation: WSUS installed on clean Server 2008R2, after KB2720211 broke WSUS on our Server 2003 box.  So we did some testing, we were planning on migrating anyway so we figured it was a good a time as any since WSUS was down and not giving updates anyway.  Install WSUS on the new server, have it use existing DB which we have on a separate SQL server.  It was moved and renamed some months ago, before I even started at this job.  

    I use existing DB in setup on new server, point to our SQL server, and WSUS wants to use SUSDB as the name (so it doesn't see the existing DB), so I let it create a new DB on SQL server. So I let WSUS create the SUSDB on our sql server.  Go into the registry modify the SqlDatabaseName key at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup and change it to our production name i.e. (Wsus_01).  Everything works fine, no problem, WSUS loads, sees all the content I migrated etc.  (Then I delete the SUSDB created in SQL since its empty and we don't need it). WSUS still won't talk to any clients that are running the new update agent however.  So I install KB2720211 as per MS instructions and POOF the console stops loading.  I do more digging online come across a lot of threads but nothing works.  Finally for some reason I take a look back in the registry and realize that after installing the update it changed the SqlDatabaseName key back to SUSDB.  It removed the name we gave it and put back the default SUSDB.  So my WSUS console was looking for a DB on my sql server that didn't exist so it wouldn't load.  Once I put back the proper name of the DB it started working again and has no problems since.

    So two things, one, if you aren't using the internal DB and you moved it to a separate sql instance and changed the name check the registry.

    Secondly, I'd like to know why this update changes that value back to the default.  I literally spent weeks trying to figure this out and our workstations we all slowly going offline as the got the new update agent.  It was very problematic, and all for something that we didn't even know got changed via this update, never once did I read that it makes modifications to the registry and resets values back to defaults.

    Anyway, I hope this helps anyone else out there that happens to be using an external DB that they renamed.

    Regards,

    Joe

    • Proposed as answer by george12345 Wednesday, October 09, 2013 7:38 PM
    Tuesday, August 28, 2012 1:28 PM
  • after installing the update it changed the SqlDatabaseName key back to SUSDB.  It removed the name we gave it and put back the default SUSDB.

    Secondly, I'd like to know why this update changes that value back to the default.

    Because you changing the database name in the first place was an unsupported configuration change, and this is exactly why it is.

    When you installed a fresh WSUS on the Win2008 server, and pointed it to your backend database, it couldn't find it because the SUSDB did not exist. When you selected to use a different SQL Server instance, it created the SUSDB there, and initialized all of the configuration values. Then when you pointed it back to the other instance -- poof! no database.

    Btw. now you know why the update failed on your original Win2003-based WSUS server!

    So, the lesson to be learned here for everybody: Don't make radical configuration changes to a product without fully understanding ALL of the implications of that change. Truth be told, there's no shortage of literature in the community pointing out that 'SUSDB' is a fixed database name and is not user-configurable.

    I would suggest setting the name back to the designed name 'SUSDB' and leave it alone, lest you have this whole nightmare again when you install KB2734608 or any other WSUS update that might come down the pipe in the future -- all of which will be looking for the 'SUSDB' and will fail if it cannot be found.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Product Manager, SolarWinds
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    Tuesday, August 28, 2012 10:32 PM
    Moderator
  • I just fell victim to this update.....  You'd think that months later they would have fixed the problem with it but NOPE!!  I've tried all above solutions and nothing is working...  Waiting for a call back from the WSUS support team and if they cant fix it I'll restore the system...  Unfreaking believable I'm completely disappointed in Microsoft for putting this garbage out for download....
    Friday, September 14, 2012 10:06 PM
  • I just fell victim to this update.....
    You'd think that for an update as old as this one, and with as many views as this thread, that nobody would be "falling victim to it" anymore.
    You'd think that months later they would have fixed the problem with it but NOPE!!
    The fact is -- there's nothing wrong with the *update*. The update works perfectly when installed on a healthy WSUS server. When installed on an unhealthy WSUS server, it exacerbates the problems that already exist. We saw exactly the same manifestation of issues when WSUS3SP2 was released in 2009. If you try to patch a broken system, almost always you'll end up with nothing more than a broken system, and sometimes an even more broken symptom.
    I've tried all above solutions and nothing is working...
    Before we talk about 'solutions', did you perform all of the 'preliminary' steps documented in the KB article? (e.g. Run the Server Cleanup Wizard, perform a System Backup?) As for the solutions -- since you've posted here after calling PSS -- let's give it a shot. What exactly are the symptoms you are observing and what exactly have you done to try to repair the system?

    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Product Manager, SolarWinds
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    Saturday, September 15, 2012 8:21 PM
    Moderator
  • I can confirm pattyworms solution:

    All you need is full access to the corresponding database. Please check the \\<server>\C$\Users\<username>\AppData\Local\Temp\MWusCa.log, or where ever it may be stored, for error massages relating to the database logon process.

    If there are such an entry, do not touch anything else but the DB rights.

    After doing that, rerun the setup.


    • Edited by erpede Thursday, September 20, 2012 2:27 PM
    Thursday, September 20, 2012 2:26 PM
  • Put the SUSDB database back into multi-user mode (might not be necessary, but I did it)

    It is worthy of note here that if the database is in single-user mode, it *MUST* be placed back into multi-user mode, and the fact that it's not in multi-user mode is the most likely single root-cause for the WSUS server's failure to operate.

    I would recommend stopping the Update Services service, put the database back in multi-user mode, restart the Update Services service, and test the WSUS server again before taking any other remediation actions. If the 'fix' is as simple as restoring normal functionality to the database --- that seems to me to be the best move.

    If the service restarts .. then retry KB2720211.

    Btw, I did not find it necessary to extract anything from the update package, I just re-ran the whole package from the command line. (Actually, truth be told, I double-clicked on it in Windows Explorer.)


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Product Manager, SolarWinds
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin


    I have limited knowledge. How do I set the DB to multi-user mode when running WSUS on 2003 Server AND the Internal DB? Please give me the exact solution and syntax if you know it. Thanks!
    Thursday, October 04, 2012 5:08 PM
  • How do I set the DB to multi-user mode when running WSUS on 2003 Server AND the Internal DB?

    The procedure is provided in the above post that I quoted the headline from:

        • Put the SUSDB database back into multi-user mode (might not be necessary, but I did it)

        1. Open a command prompt as administrator and run "iisreset /stop"
        2. Stop the "Update Services" service if running (it usually isn't since it's broken at this point)
        3. Open SQL Server Management Studio as Administrator (Start > Programs > Microsoft SQL Server 2008 R2)
        4. Under Server type, select "Database Engine", for server name, use "\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query", and for Authentication use "Windows Authentication". Click Connect.
        5. Look at your SUSDB (Databases > SUSDB). If it is in single-user mode, open its properties, go to the Options screen, and set the Restrict Access setting to "MULTI_USER". Let it reset connections if needed.
        6. Reboot your server (might not be necessary, but I figured it was best to play it safe)
        7. You might see a lot of MSSQL$MICROSOFT##SSEE event 33002 in the logs after the reboot, but you can ignore these for now since the patch "should" fix it in a bit.

    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin


    Friday, October 05, 2012 10:39 PM
    Moderator
  • You'd think that for an update as old as this one, and with as many views as this thread, that nobody would be "falling victim to it" anymore.

    Come on, Lawrence!

    1. It is a WSUS update (and Critical Update), so it is automatically approved (at least with the default wsus setup in my SBS box; I cannot remember whether it is the default in any wsus).

    2. Do you seriously expect everybody googling for possible problems with every update from MSoft before applying it?

    I understand your concern about people making weird changes in wsus config ( renaming SUSDB :-o ) ,  but this update could have been marked other way (just as old "hotfixes") after having caused so many pains so difficult to heal. It is my opinion, of course ;-)

    Regards,
    Rodeca

    P.S. BTW: I haven't had any problem with it: my wsus (two boxes up/down-stream) are working well; I found this thread lookinf for another "starting wsus" issue

    Friday, November 16, 2012 4:17 PM
  • You'd think that for an update as old as this one, and with as many views as this thread, that nobody would be "falling victim to it" anymore.

    Come on, Lawrence!

    1. It is a WSUS update (and Critical Update), so it is automatically approved (at least with the default wsus setup in my SBS box; I cannot remember whether it is the default in any wsus).

    Such is the inherent flaw in automatically approving updates of any type; more specifically -- the critical flaw in automatically (or blindly) installing updates to a server, much less a Domain Controller! (Never mind that it's a WSUS server, but that's also problematic, in itself.)

    The automatic update rule is DISABLED, by default, on all native WSUS servers. It is ENABLED, by default, on SBS implementations. Kindly, send your gripes about that state of affairs to the SBS team.

    2. Do you seriously expect everybody googling for possible problems with every update from MSoft before applying it?

    I think that reasonable systems administators will do a modicum of research of the potential impact of an update before installing it to a server, particularly a Domain Controller, and moreso if it's the only server running the entire company -- so YES, I do expect that in some cases. The JOB requires that behavior to be done properly.

    I also think that patch administrators (whatever their primary role in their organization might otherwise be; there's no such thing as a full-time patchAdmin) ought to be doing a modicum of research before unilaterally installing ANY update in the environment, much less on the WSUS Server, or other critical server systems. I am, to put it succinctly, universally and vehemenly opposed to the idea of automatically approving-and-installing any update by product or by classification.

    I also think that WSUS Administrators ought to be particularly cognizant of the potential impact of updates being applied to the *WSUS* server -- wherever that might reside. Given that I can count the total number of *WSUS* patches on one hand throughout the lifetime of the product (that's five patches, now, in almost eight years), I don't find it unreasonable at all.... just as I would not find it unreasonable that:

    • A DBA would be particularly cognizant of the potential impact of updates to Microsoft SQL Server.
    • An Exchange Administrator would be particularly cognizant of the potential impact of updates to Microsoft Exchange Server.
    • A Sharepoint Administrator would be particularly cognizant of the potential impact of updates to Microsoft Sharepoint Services.
    • A Domain Administrator would be particularly cognizant of the potential impact of updates to a Domain Controller.
    • A Security Administrator would be particularly cognizant of the potential impact of security updates to the enterprise.

    The gray area, of course then, is organizations blindly reliant upon the automatic patching mechanisms built into the SBS idiot-proofing customizations, and the general lack of novice expertise in any one of the above products, ALL of which exist on a Small Business Server!

    I don't particularly like what the SBS team did to their WSUS implementation (see previous thought on auto-approval and auto-install) , and sometimes the problem is that business owners implementing SBS are, legitimately and understandably, clueless as to the ramifications of those idiot-proofed customizations. Sometimes the "IT Consultant" they hired to implement the SBS is equally as clueless (but not equally less-than-culpable).

    However, just in case there's any doubt -- the only thing idiotic in all of this was the decision by the SBS team to enable that automatic-approval rule AND configure the SBS server to automatically INSTALL those updates. So again -- the issue is not *WSUS* -- it is the particular *implementation* of WSUS that comes with SBS, so kindly direct your absolutely justifiable wrath at the correct parties. :-)

    I understand your concern about people making weird changes in wsus config ( renaming SUSDB :-o ) ,  but this update could have been marked other way (just as old "hotfixes") after having caused so many pains so difficult to heal. It is my opinion, of course ;-)

    FWIW... the powers that be wisely chose to NOT release KB2734608 to MU or WSUS.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    Friday, November 23, 2012 8:54 PM
    Moderator
  • For the record only SBS 2003 automatically approves and installs updates on servers.  SBS 2008 and 2011 changed the defaults.  Patches are approved and downloaded but not automatically installed.  SBS does not blindly install updates, the admin still has to choose to install them.

    The fact of the matter is this has barfed on normal WSUS so how about we go back to blaming Microsoft for putting out such a creaky update that relies on having to have a pretty well maintained WSUS setup not to barf.  I never had problems.  But there's a ton of WSUS admins - and not just SBS - that barfed on this one.  So it's not just SBS Lawrence.  It's WSUS that ultimately is having the problem installing this update.  If the underlying SBS implimentation was at fault, I'd be hitting this issue.  I didn't.

    If this update needs WSUS to have a WSUS cleanup task run before installing it, then how about including that info IN the KB in the first place?

    Friday, November 23, 2012 10:12 PM
  • UMMM, Lawrence, you just _may_ want to check your own servers there son.

    Now how do I say this politely?

    You see Lawrence, I just wasted a small amount of my Saturday morning to confirm what I thought to be true. I installed Windows Server 2008 R2 doing a standard 'base install' and then enabled the WSUS Role.

    With no choice to do so on my part WSUS is set to 'Automatically approve updates to the WSUS product itself', 'out of the box' and 'on Server Standard'.

    Please constrain your complaints about SBS to what SBS does in non-standard manner. We (SBSers) have enough problems of our own, without being blamed for those of WSUS.

    BTW: Both SBS08 and SBS11 have a 'post installation wizard' from a link in the console headed 'Configure Software Update Services'. An SBS implementer _GETS TO CHOOSE_ just how updates are handled, to further granularity than that given 'standard WSUS admins'.

    EDIT: typo, on Lawrence name, no less. I had to correct that.
    • Edited by SuperGumby Friday, November 23, 2012 11:14 PM
    Friday, November 23, 2012 11:13 PM
  • Can yo advise on how to fix if you have no backup of SUSDB.mdf & SUSDB_log.ldf files please?
    Monday, November 26, 2012 10:26 AM
  • If this update needs WSUS to have a WSUS cleanup task run before installing it, then how about including that info IN the KB in the first place?

    It is.

    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    Saturday, December 01, 2012 1:35 AM
    Moderator
  • With no choice to do so on my part WSUS is set to 'Automatically approve updates to the WSUS product itself', 'out of the box' and 'on Server Standard'.

    So? KB2720211 is not contained in that category of updates.

    And this default applies to all installations of WSUS, it is not specific to SBS.

    I'm not grasping how this is relevant to KB2720211 or the issues that have been encountered with that update.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    Saturday, December 01, 2012 1:37 AM
    Moderator
  • Can yo advise on how to fix if you have no backup of SUSDB.mdf & SUSDB_log.ldf files please?
    Reinstall.

    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    Saturday, December 01, 2012 1:37 AM
    Moderator
  • This link worked for me !!!! 

    That worked really fantastic !!

    Follow it "As- Is"

    http://social.technet.microsoft.com/Forums/en-US/winserverwsus/thread/a47039d9-4d45-4a61-aa26-6100aeffc1f0

    Work it out and please let me know if it helped...

    • Proposed as answer by Chintan Vyas Tuesday, December 04, 2012 5:52 PM
    Tuesday, December 04, 2012 5:52 PM
  • Had the same issues as on this thread.

    None of the options/fixes provided a solution.

    Finally opened a work order the MS tech support.  Told me to install KB2734608 and it everything is now working.  This update includes 2720211.

    cheers

    Thursday, December 13, 2012 10:24 PM
  • The following link gives the same suggestion:  

    http://social.technet.microsoft.com/Forums/en-US/winserverwsus/thread/a47039d9-4d45-4a61-aa26-6100aeffc1f0

    Regards,

    Tuesday, December 18, 2012 6:35 AM
  • Finally opened a work order the MS tech support.  Told me to install KB2734608 and it everything is now working.  This update includes 2720211.

    I disagree, we got this problem after installing KB2734608.

    Solution was to replace the three files WSUSSignDb.cer, WSUSSignDb.dll and WSUSSignDb.sql.

    January 6th, and counting.

    Sunday, January 06, 2013 1:37 PM
  • I actually found this before I installed the fix and chose this fix because it was the most straight-forward. It worked great!
    Tuesday, January 08, 2013 4:42 PM
  • Hi:

        KB2734608 works fine for me on Windows 2003 R2 new installation.

    Thursday, November 07, 2013 7:29 PM
  • I successfully recovered WSUS without changing too much - hopefully this will work for others. The catch is you have to have a recent backup of your WSUS database.

    Step 1: Download the KB2720211 from Microsoft: http://support.microsoft.com/kb/2720211

    Step 2: Open Regedit, and change the value of this DWORD to 0: "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup\wYukonInstalled"

    Step 3: Install KB2720211

    Step 4: Change the DWORD value back to 1

    I didn't do Step's 5, 6 and 7.

    Installed KB2720211 and restarted the WSUS serrver and was fine. Local MMC/Remote WSUS snap-ins, full sychronization and clients all work.

    Wednesday, November 27, 2013 12:15 AM
  • it works on my case, many thanks Darin Booker...
    Tuesday, May 27, 2014 6:13 AM