wsus patch 954960 install fails...
- So I'm trying to install the 954960 patch on one of my replica wsus servers. The installation fails and this log is written: We are using the internal atabase rather than a remote sql install...
2009-11-06 11:06:02 Success CustomActions.Dll Successfully set propery of WSUS admin groups' full names
2009-11-06 11:06:02 Error CustomActions.Dll ExecuteQuery: Failed to execute SQL query EXEC dbo.sp_helpdb 'SUSDB' (Error 0x80040E14)
2009-11-06 11:06:02 Error CustomActions.Dll ExecuteQueryGetMultipleResults: Failed to execute query EXEC dbo.sp_helpdb '%s' (Error 0x80040E14)
2009-11-06 11:06:02 Error CustomActions.Dll GetDatabaseLocation: Failed to execute SQL query EXEC dbo.sp_helpdb '%s' (Error 0x80040E14)
2009-11-06 11:06:02 Error CustomActions.Dll SetWyukonInstallDirProperty: Failed to get installed location of SUSDB in WYukon (Error 0x80040E14)
2009-11-06 11:06:02 Error CustomActions.Dll SetUnInstallProperties: Failed to set WYUKON install directory (Error 0x80040E14)
Any Ideas??
Thanks...
Answers
I find it funny that a fresh install would also give this error immediately after reinstall, no?
Not if the System ACLs are FUBAR and you've not performed a complete installation of a fresh operating system.I installed SQL server management studio express to verify that my rights were proper which they were.
I'm not sure I follow how installing SSMS establishes that the database permissions for WSUS are correct.Seems like there are people out there getting this error, but no definitive resolution exists.
As noted in my previous reply, for those who stuck with the diagnostics, a resolution was identified, and was, in every case, a flaw in ACLs. For those who chose to abandon the diagnostics and reinstall from scratch -- we'll never know.
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
My Blog: http://onsitechsolutions.spaces.live.com- Marked As Answer byEric Zhang - MSFTMSFT, ModeratorMonday, November 16, 2009 4:26 AM
All Replies
So I'm trying to install the 954960 patch on one of my replica wsus servers.
It would be preferable to upgrade the server to WSUS3SP2. If the server already is WSUS3SP2, then this update is not applicable.The installation fails and this log is written:
This issue has occurred a very few other times. In the two threads in which the poster followed through with the suggested diagnostics and remediations, the issue was traced to the modification of security permissions on the WSUS Server.
2009-11-06 11:06:02 Error CustomActions.Dll ExecuteQuery: Failed to execute SQL query EXEC dbo.sp_helpdb 'SUSDB' (Error 0x80040E14)
In this thread, the \WSUS folder did not have the correct permissions for the NETWORK SERVICE account.
In this thread, issues with the security permissions of the database were identified as a possible cause, as well as the possibility that the update was being installed in the context of a user who did not have the requisite database permissions (i.e. a member of the local Administrators account), and also references another thread where I observed the removal of the EVERYONE account from the ROOT of the drive. The EVERYONE account should have Read&Execute permissions on the ROOT of every volume on the server, and NOT inherited downward.
The other two threads (this thread is only the fifth to present this specific error) were abandoned by the original poster and it is unknown what, if anything, was done to remediate the situation.
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
My Blog: http://onsitechsolutions.spaces.live.comThis issue has occurred a very few other times. In the two threads in which the poster followed through with the suggested diagnostics and remediations, the issue was traced to the modification of security permissions on the WSUS Server.
In this thread, the \WSUS folder did not have the correct permissions for the NETWORK SERVICE account.
In this thread, issues with the security permissions of the database were identified as a possible cause, as well as the possibility that the update was being installed in the context of a user who did not have the requisite database permissions (i.e. a member of the local Administrators account), and also references another thread where I observed the removal of the EVERYONE account from the ROOT of the drive. The EVERYONE account should have Read&Execute permissions on the ROOT of every volume on the server, and NOT inherited downward.
The other two threads (this thread is only the fifth to present this specific error) were abandoned by the original poster and it is unknown what, if anything, was done to remediate the situation.
There is more to this story though - I reinstalled wsus 3.0 sp1 from scratch because I got this same error when running the sp1 upgrade. This server happens to be a replica server, so I was able to reinstall and download from the upstream and all was well. I find it funny that a fresh install would also give this error immediately after reinstall, no?
I also went down the route of database permissions as you allude to in your second referenced thread. I installed SQL server management studio express to verify that my rights were proper which they were.
I also tried the right thing in your first referenced thread, but it still fails with the same error...
Seems like there are people out there getting this error, but no definitive resolution exists.I find it funny that a fresh install would also give this error immediately after reinstall, no?
Not if the System ACLs are FUBAR and you've not performed a complete installation of a fresh operating system.I installed SQL server management studio express to verify that my rights were proper which they were.
I'm not sure I follow how installing SSMS establishes that the database permissions for WSUS are correct.Seems like there are people out there getting this error, but no definitive resolution exists.
As noted in my previous reply, for those who stuck with the diagnostics, a resolution was identified, and was, in every case, a flaw in ACLs. For those who chose to abandon the diagnostics and reinstall from scratch -- we'll never know.
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
My Blog: http://onsitechsolutions.spaces.live.com- Marked As Answer byEric Zhang - MSFTMSFT, ModeratorMonday, November 16, 2009 4:26 AM
