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

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

  • Comments 4
  • Likes

[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 Files\Common Files\Microsoft Shared\Web server extensions\12\BIN\psconfig -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 Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN>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 Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN>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 Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN>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

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
Comments
  • Some notes for step (2):

    1. On first run, it bombed complaining about a SQL connection timeout at "Task upgradebootstrap." Seems to be just because it is trying to execute a gigantic SQL script and running out of time.

    2. On second and third run, it bombed (earlier in the process) saying that it couldn't detect if it was on a server farm at "function Farm.TryIsJoinedToFarm."

    3. Ran iisreset /restart and re-ran the command a fourth time. Took about 40 minutes but finished successfully this time.

  • I encountered this issue with SBS2008 and KB983444, but the above commands would not complete successfully for at least 6 tries.

    HOWEVER, after uninstalling GroupBoard 2007 (an additional WSS template application) from the SBS2008 box and restarting the SharePoint services and IIS, I could run the PSCONFIG GUI from the Admin Tools menu and it completed successfully.

    I hope this helps someone, as this has taken me a week and a whole load of late nights to get back.....

    Steve

  • I've been trying to fix this for a couple weeks after seeing a huge spike in errors in the event log. This particular company doesn't even us SharePoint, but I like a very clean server. Anyway, the search service tweak allowed me to successfully run the SPTCW wizard. Now the SharePoint companyweb site works fine locally or via RWW.

    Thanks for the great article!

    JD

  • Is not working for me. Do you know who should I submmit the log files in Microsoft? I really believe that this one has to be solved by Microsoft since it is the result of applying an update.

    Best regards

    Arturo