I noticed one of the servers was generating issues related to ssl which was very curious because i hadn’t configured ssl.  After some sifting through logs i came upon this entry…

05/05/2009 16:38:27.95 OWSTIMER.EXE (0x0C44)                     0x0F04 Search Server Common              MS Search Administration               86ze     High      Exception caught in Search Admin web-service proxy (client). System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Authentication failed because the remote party has closed the transport stream.     at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)     at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)     at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)     at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)     at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallba...     

This tells me that MOSS is trying to communicate to Office Shared Services for intra server ssp communication using SSL. 

After sifting though support tickets i noticed people were fixing similar issues by fixing the SSL cert assigned to Office Server Shared Services Web Service Web site. 

Finally i came upon this support KB which describes how to fix it, apparently .NET 3.5 SP1 breaks the ssl cert.  Still curious why SSL is being used if i didn’t configure it. 

https://support.microsoft.com/kb/962928

When i investigated it more most of the site was working with the exception of the Pages.  My guess was that the pages lost their association to the Page Layouts when i moved the site. 

I solved this by deleting all of the pages and recreating them. 

Hope this helps someone. 

This has been resolved by the product team with an updated build. 

Problem:

I installed the December updates as mentioned here SharePoint Team Blog Post and thought everything would just be as smooth as silk but that expectation was a little off.  The configuration failed with very little information. 

Since i’ve seen configuration fail a few times at clients i decided to expand my options by using the command line options on msdn 

using this command produced an upgrade.log file in the trace logs directory

psconfig.exe -cmd upgrade -inplace b2b –force

The upgrade log produced this error 

[SPSearchDatabase Name=WSS_Search_DBNAME Parent=SPDatabaseServiceInstance Name=OfficeServers] failed.
[SPManager] [ERROR] [12/18/2008 9:48:22 AM]: Object reference not set to an instance of an object.
[SPManager] [ERROR] [12/18/2008 9:48:22 AM]:    at Microsoft.SharePoint.Upgrade.SPSearchDatabaseAction.GetSearchContextSearchSqlStringValue(String stringName)
   at Microsoft.SharePoint.Upgrade.SearchQFE23318DatabaseAction.Upgrade()
   at Microsoft.SharePoint.Upgrade.SPActionSequence.Upgrade()

From this i guessed that it couldn’t upgrade the WSS Search DB which can easily be deleted and recreated. So i turned off the WSS Search Service and upgrade worked fine.  

Solution:

Turn off WSS Search in Central Admin and Upgrade then turn back on. 

With some more troubleshooting i came to this error in the trace logs on the index server which indicates backup is not the culprit but something to do with Search or the SSP not having the right permissions

11/19/2008 13:56:47.31 w3wp.exe (0x119C)                                0x0D78 Search Server Common              MS Search Administration               86z4     High      Exception caught in Search Admin web-service (server). System.UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))     at Microsoft.Office.Server.Search.Administration.SearchApi.RunOnServer[T](CodeToRun`1 remoteCode, CodeToRun`1 localCode, Boolean useCurrentSecurityContext, Int32 versionIn)    

I was able to get around this by giving the SSP Service Account/App Pool admin permissions on the index server.  I’m sure it was a more granular permission that could have fixed this issue but i didn’t have the time to troubleshoot this issue and the SSP Service Account is not externally exposed so our exposure is limited. 

If you receive an warning in your event log with event id 2436 - "Access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content.   (0x80041205)". 

or this one in your crawl logs

Access is denied. Verify that either the Default Content Access Account has access to this repository, or add a crawl rule to crawl this repository. If the repository being crawled is a SharePoint repository, verify that the account you are using has "Full Read" permissions on the SharePoint Web Application being crawled. (The item was deleted because it was either not found or the crawler was denied access to it.) 

After a day of banging my head against my desk i figured out that Loopback check needed to be disabled.  Interesting that IIS 7 isn't mentioned in the KB.  Here's the Disabling the Loopback Check KB.   

Here's where the fun starts.  We start receiving Cannot generate SSPI context errors from sharepoint and KRB_AP_ERR_MODIFIED errors from kerberos logging.

So after a lot of searching we found that the error was staring us in the face.  We had named the sql service account the same as the machine name.  When they are the same name kerberos gets confused about the SPN.  So the fix was to rename the sql service account and redo the SPNs.  After rebooting all of the MOSS boxes, everything worked. 

Here's the code I used to accomplish this...

FileExtensionService.cs

-------------------------------

using System.Collections.Generic;
using System.Text;
using msa=Microsoft.Office.Server.Search.Administration;
using ma = Microsoft.SharePoint.Administration;
using System.Web.Services;
using System.Web;
namespace Samples.SharePoint.WebServices
{
    [WebService]
    public class FileExtensionService
    {
        const string GetFileExtensionsCacheString = "FileExtensionService.GetFileExtensions";
        public FileExtensionService()
        {
        }
        [WebMethod(Description="Gets the Extensionlist out of moss")]
        public string[] GetFileExtensions()
        {

            List<string> extensions = HttpContext.Current.Cache[GetFileExtensionsCacheString] as List<string>;
            if (extensions == null)
            {
                extensions = new List<string>();
                Microsoft.Office.Server.ServerContext server = Microsoft.Office.Server.ServerContext.Default;
                msa.SearchContext context = msa.SearchContext.GetContext(server);
                msa.Content ssp = new msa.Content(context);
                foreach (msa.Extension extension in ssp.ExtensionList)
                {
                    extensions.Add(extension.FileExtension);
                }
                HttpContext.Current.Cache[GetFileExtensionsCacheString] = string.Concat(".",extensions);
            }
            return extensions.ToArray();
        }
    }
}

Now I'm improving that post with a new sample that will automate the report deployment based on an xml file.  I will utilize a file called ReportsDefinition.xml to upload the reports to a document library within SharePoint.  The Reports will be upload from a directory within the feature directory.  I've included a sample Reports Definition file and sample reports to show you how it works.  Read the ReportsDefinitionDataSet.xsd to see what each parameter does. 

I'm using the WSP builder project to create a WSP.  You can utilize the WSP file to deploy you're code.

Updated Link: 

Sample Code is here - https://www.codeplex.com/ssrsfeaturebuilder/