I was doing an install recently and a client happened to have installed the .NET Framework 3.5 SP1 on the servers i was working.  The first environment i installed was a two server environment (1 SharePoint, 1 SQL) and everything was working fine.  When i moved to a 5 server environment and started the install i started getting access denieds on the search administration page and profile administration page. 

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. 

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

I was recently doing an stsadm –o restore to restore a backup and was able to successfully move my production site collection backup to test.  When i went to the site it mostly worked with the exception of one subsite.  One subsite was returning a COM error "There are no more files" with a COM error code 0x80070012.

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. 

UPDATE:

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. 

Was recently working with a client working on backup and came across this error

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. 

So i created a new vm using Windows Server 2008, SharePoint Server 2007 + SP1 + Infrastructure updates.  I'm also using a least priveleged account setup with least priveleged accounts running the individual MOSS Services and app pools.  When I started a crawl of local office sharepoint server sites i noticed i was getting 401'ed by SiteData.asmx.  

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.   

Another live MOSS site is out there.  http://www.XcelEnergy.com. 

So we setup Kerberos on SharePoint using one of the many guides out there.  Everything worked great but SQL Server was returning KDC_ERR_S_PRINCIPAL_UNKOWN which is typical.  So we registered an SPN for SQL Server using "Setspn -A MSSQLSvc/sqlboxhostname:1433 domain\sqlserviceaccount" and "Setspn -A MSSQLSvc/sqlboxfqdn:1433 domain\sqlserviceaccount". 

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. 

I recently had to expose the file extensions that we allow search to index outside of SharePoint.  Unfortunately SharePoint does not expose this out of the box.  So i had to write a web service to be deployed in MOSS that would expose the file extension list.

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();
        }
    }
}

I had made a previous post with a small code sample on how to upload report deployment. 

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 - http://www.codeplex.com/ssrsfeaturebuilder/

Hoping this might be a good topic for some people because i guarantee there are very few people who have been through integrating these products. 

I have been working on integrating the two products at a client for the past 5 months so hopefully this will help someone out. 

SharePoint as a fit for Legal Discovery 

Legal discovery has very different requirements vs. enterprise search. MOSS is a relevance based search engine which means that searches conducted by a user are matched against content in the MOSS index using various rankings like link depth from authoritative sources, document type rankings(e.g. Word is ranked higher than Excel), word repetitions within a document, the number of times a document is linked to and etc… A certain portion of document is indexed (e.g. the first 15 MB) after which content is not termed relevant. Documents over a certain size are also not indexed out of the box. All of this can be adjusted by configuration but my point is that MOSS is purely focused on making the most relevant content available to a searcher. 95% of the time the average user never goes beyond the first page of results. This is why relevancy is so important for your average user and why the system is tuned for it. Legal discovery seems to be focused on a very different search. The legal user often times wants to view all search results and to search the entire document of every document indexed by MOSS. The legal user wants to put those results into a workflow to be saved off on a case by case basis. MOSS is not tuned to these needs. I will detail the biggest risks that MOSS introduces for a Legal discovery based search.

Gaps and Mitigations

Symantec Integration Issues - MOSS Search Collisions with File Shares

Symantec Enterprise Vault is capable of archiving file shares.  This means files on file shares will be replaced with placeholders.  The SharePoint crawler does not recognize the difference between a placeholder and a file on the file system. 

The question becomes do you want to crawl files that have been archived? 

Our answer was no, since the Symantec Enterprise Vault builds its own index why have two.  Also this lightens the load on the MOSS index.  The behavior we witnessed is that MOSS would continue to pull items out of the vault when they are archived. The only way to prevent this is through putting Symantec Enterprise Vault in backup mode and adding the crawl account to the backup group.  This however will flood the crawl log with errors.  So not the best option either if you want search to remain manageable. 

The best option would be if the Crawl account could ignore documents with the offline attribute.  This is not currently available in MOSS but hopefully one day it will be.   

Update: This has been fixed in the MOSS August 2008.  It's not very clear from the notes but here it is...http://support.microsoft.com/kb/956056/.  “When you try to crawl a content source, the offline files in the content source are indexed unexpectedly. The offline files are the files that have the PR_FILE_ATTRIBUTE_OFFLINE attribute set.
Note After you apply the hotfix, offline files will are not indexed any longer”

Search Integration with Symantec Enterprise Vault

If you want to search MOSS and Enterprise Vault from a single interface today you're only option is custom code calling the EV COM interfaces.  This is very complicated code to write.  Luckily around the end of year Symantec will release a new version that supports Search Federation so a single interface can be used. 

Search Federation still does not cover the Discovery Accelerator product.  It's the one product i feel should be integrated into MOSS.  It would be beneficial if there were workflows that could launch out of MOSS search into DA.  I have heard that DA will be able to federate queries back to MOSS however so when a legal user is within the DA interface MOSS search results can appear.  This is due in the next release of Symantec EV.

Hope i helped someone with my thoughts around legal discovery, please feel free to comment.

Updated: You should not register the trace provider on every request.  Use a singleton to check for registration.

Found a great example on how to write to the SharePoint trace log on msdn.  http://msdn2.microsoft.com/en-us/library/aa979522.aspx.  This is very helpful for doing application instrumentation.  Although there are many apis for doing this in .NET very cool to be able to have all the info in one place for the product.  Additionally here's some sample code for correlating traces together in httprequests. 

           string product = "Trace Provider";
           string category = "Runtime";
           string exeName = "SharePoint TraceWriter";
           string message = string.Concat("Time{", DateTime.Now.ToLongTimeString(), "} :: Message{", message, "}");

           //Get correlation string
           Guid guid = Guid.Empty;
           object guidObject = null ;
           if (HttpContext.Current != null)
           {
               guidObject = HttpContext.Current.Items["TraceGuid"];
           }
           if (guidObject == null)
           {
               guid = Guid.NewGuid();
               HttpContext.Current.Items.Add("TraceGuid", guid);
           }
           else
           {
               guid = (Guid)guidObject;
           }

           System.Diagnostics.Debug.WriteLine(message);
           System.Diagnostics.Trace.WriteLine(message);
           SPSecurity.RunWithElevatedPrivileges(
            delegate()
            {
                //Write to sharepoint trace
                TraceProvider.RegisterTraceProvider();
                TraceProvider.WriteTrace(0, TraceProvider.TraceSeverity.Monitorable, guid, exeName, product, category, message);
                TraceProvider.UnregisterTraceProvider();
            }
          );

SharePoint by default does not support taking IE out of quirks mode.  This is discussed in a great blog entry by Heather Solomon.  Not enforcing a dtd through the DOCTYPE element in the default.master (for example
DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"  "http://www.w3.org/TR/html4/loose.dtd")

Caused me a lot of problems since Height 100% is not honored.  Specifically the Reporting Services Add-in for Sharepoint is reliant on the height=100% property of tables.  It was necessary for me to include the doctype then.  This created some other issues in that it broke some of the other scripts in sharepoint.  This is because when ie is in quirks mode document.body is the root document element but when the DOCTYPE is applied, document.documentElement becomes the root element.  Alot of these discoveries can be made using script debugging in IE

Here's a sample of a script i had to change in IE55UP.js....

function MSOLayout_GetRealOffset(StartingObject,OffsetType, EndParent)
{
 var realValue=0;
 if(!EndParent) EndParent=document.documentElement;
 if(EndParent==null){
     EndParent = document.body;
 }
 for (var currentObject=StartingObject; currentObject !=EndParent && currentObject !=document.documentElement && currentObject !=document.body; currentObject=currentObject.offsetParent)
 {
  realValue+=eval('currentObject.offset'+OffsetType)
 }
 return realValue;
} 

1. Install SQL Server 2005 - Reporting Services Only
2. Install SQL Server Service Pack 2
3. Install Sharepoint (as WFE)- SKU (Enterprise Edition, Standard,etc..) has to match the other SKUs in the farm
4. Run the Sharepoint Server Configuration (do not add central admin unless you want to) - Not sure if this step is needed but can't hurt
5. Install the reporting services add-in for sharepoint
6. Run the Reporting Services Configuration Utility [start-->all programs-->microsoft sql server-->configuration-->reporting services configuration]
7. Create the ReportServer Virtual Directory (ReportServer) preferably
8. ReportServer AppPool and Reporting Services Windows Service should both be a domain account
9. Create the Database (create the database in Sharepoint integration mode) -
10. (Here's the Trick) - the Website that contains the report server vdir attempts to negotiate authentication by default.  This is not needed if you are not configuring kerberos. 
11. To fix this if you do not intend to use kerberos, open a command prompt, cd to c:\inetpub\adminscripts\
12. First check to see if there is an authentication provider run cscript "adsutil.vbs get w3svc/{WebSiteId}/root/NTAuthenticationProvider" ({WebSiteId} being the id for the website containing the RS Vdir), this should return [The parameter "NTAuthenticationProviders" is not set at this node.]
13. Then run [cscript adsutil.vbs set w3svc/1/root/NTAuthenticationProviders "NTLM"]
14. This should return [NTAuthenticationProviders       : (STRING) "NTLM"]
15. Next go to Sharepoint central administration and enable the reporting services feature and then configure the rest of reporting services within application management.  Be sure to set the authentication method to Trusted Account. 
16. For more information on this see - http://blogs.msdn.com/sharepoint/attachment/4194088.ashx

Better late than never - http://support.microsoft.com/kb/939942

If you've been trying to put a transparent image into reporting services and have not been able to make the background transparent i share your pain. Luckily i found a solution.

1. Place a rectangle where you would place the image

2. Place the image inside the rectangle

3. That's actually it.

Simple and not straightforward at all. Can't wait for CSS support in Katmai!