Companyweb and SharePoint Central Admin not accessible after installing KB983444 or KB2345304

First published on TechNet on Jun 18, 2010
[ Today’s post comes to us courtesy of Shawn Sullivan and Damian Leibaschoff from Commercial Technical Support and Chris Puckett from Product Quality ]

We wanted to give everyone an update on the current situation with update 983444 and Small Business Server 2008 and to try to help anyone that is having problems. The majority of our customers should not have any problems with this update on SBS.  For those who are running into this issue, the solution is very simple in most cases and we see a very high success rate. However, for some it is a little more complex. What we document below has helped the majority of the situations where this issue has been seen.

[Updated Content:  10/15/2010]

We have recently begun to see the same behavior surrounding the installation of 2345304 (MS10-072: Description of the security update for Windows SharePoint Services 3.0: October 12, 2010).  For this scenario, the steps towards resolution are the same as those given below.

Background:
The first thing we want to clarify is how SharePoint 3 updates are being installed. There are two main phases (detailed description < link >) Phase one is the binary deployment, this is where the actual SharePoint files are updated. The second phase is the provisioning of the databases, if for any reason the provisioning doesn’t complete, your sites will be inaccessible. You may see errors similar to the ones mentioned on this blog post “ Companyweb Inaccessible After SharePoint 3.0 Service Pack 2 ”, also, you may see an event with an error mentioning the text “Invalid Signature” or “missing Windows Internal Database signatures.". Almost all of this issues we have seen on this update is phase two failing.

Solution:

For most issues the resolution will be to be to forcefully finish phase two and complete the provisioning of the databases. To do this, follow these steps:

1. Open the Services snap-in and Restart the Windows Internal Database service.
2. Run the following command from an elevated command prompt (if the command fails, note the error and run the command again, in some occasions due to some timing considerations, it might have to be run multiple times before it works, we would suggest trying it 2 or 3 times).
   1. C:Program FilesCommon FilesMicrosoft SharedWeb server extensions12BINpsconfig -cmd upgrade -inplace b2b -wait -force
   2. The command may take a long time to run. If it completes successfully, SharePoint Central Admin and Companyweb should work (confirm IIS services are running, bindings are correct, etc.)
3. After the psconfig completes, check the following:
   • If SharePoint Central Admin works but Companyweb does not, check the bindings for the web site in IIS, we’ve seen some cases where they are missing.

The previous steps take care of most of the issues, on a few others we’ve seen issues with abnormally configured custom accounts for the Search Service causing problems. Here is a quick workaround to get you through the issue back to a working CompanyWeb if you are indeed hitting this issue.

1. To verify that the Local Service account is being used for SharePoint Search, do the following:
   1. Click on Start > Run and type services.msc
   2. Right-click on the Windows SharePoint Services Search service and choose Properties
   3. Click on the Log On tab.  If the account is anything other than Local Service , proceed with the following steps.
2. To fix this, use stsadm to unprovision the search service so you can finish psconfig.  After that, you should be able to access Sharepoint Central Administration to fix the login account and restore the functionality of SPSearch:
   1. Open an elevated cmd prompt and run the following command:
      C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12BIN>STSADM.EXE -o provisionservice -action stop -servicetype "Microsoft.SharePoint.Search.Administration.SPSearchService, Microsoft.SharePoint.Search,Version=12.0.0.0,Culture=neutral, PublicKeyToken=71e9bce111e9429c" -servicename spsearch
   2. Complete Steps 1-3 from the previous section. Once they complete and you have a working SharePoint Central Administrator and CompanyWeb sites, proceed to the next set of steps.
3. Change the login account for SPsearch to Local Service.
   1. Open Sharepoint Central Administration > Operations > Services on Server
   2. Click on Windows SharePoint Services Search
   3. Select Local Service under predefined for service account and content access account, then click OK
4. Use stsadmin to reprovision the spsearch service:
   1. From an elevated cmd prompt, run the following command:
      C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12BIN>STSADM.EXE -o provisionservice -action start -servicetype "Microsoft.SharePoint.Search.Administration.SPSearchService, Microsoft.SharePoint.Search,Version=12.0.0.0,Culture=neutral, PublicKeyToken=71e9bce111e9429c" -servicename spsearch
5. You will not see any search results in SharePoint until a full crawl has been initiated and is successfully indexing the content.  To trigger this, use stsadm:
   1. From an elevated cmd prompt, run the following command:
      C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12BIN>STSADM.EXE -o spsearch –action fullcrawlstart

Important: If you are receiving event 2436 for Windows SharePoint Services 3 Search after initiating the full crawl, then you need to follow the steps that are documented in the following blogpost: Event 2436 for SharePoint Services 3 Search .  In fact, we have seen the occurrence of this issue become the reason why many customers change the login account for spsearch as an attempted workaround.

Check the following KB article for other known issues:

KB 944267 How to troubleshoot common errors that occur when you run  the SharePoint Products and Technologies Configuration Wizard on a computer that is running Windows SharePoint Services 3.0 or SharePoint Server 2007


For similar issue on SBS 2011 Standard, please check the following blog:

http://blogs.technet.com/b/sbs/archive/2011/05/24/you-must-manually-run-psconfig-after-installing-sharepoint-2010-patches.aspx