SharePoint Search Exception: The server did not provide a meaningful reply

Recently I had to configure search sometime after the initial build, which was done using AutoSPInstaller. To ensure consistency of approach, I created a slightly modified version of AutoSPInstallerMain.ps1 and also XML AutoSPInstallerInput files. The only real difference in the XML file was that I was instructing AutoSPInstaller to provision search, and also that I was instructing it to not provision Central Admin (as this was already provisioned and I have experienced the script failing when CA had already been created). The main difference in the AutoSPInstallerMain.ps1 was that I commented out a lot of the entries in the Setup-Services function (i.e. to only run StartSearchQueryAndSiteSettingsService and CreateEnterpriseSearchServiceApp).

Shortly after the installation/configuration of Search, users were experiencing a correlation exception when performing searches. The ULS log returned the error 'Internal server error exception: System.ServiceModel.CommunicationException: The server did not provide a meaningful reply; this might be caused by a contract mismatch, a premature session shutdown or an internal server error.'. Subsequent messages also included 'A runtime exception was detected. Details follow. Message: Thread was being aborted'.

To fix this issue I had to do the following:
1) On each SharePoint Server, modify the permissions to the C:\Windows\Temp directory to ensure that the WSS_WPG group had both read and write access (by default after the Search installation, this group only had read access)
2) Restart the 'SharePoint Server Search 14' search on each server.

Once this was done, search began to work. Hope this helps someone.

Upgrading a Custom Search Results XSLT from 2007 to 2010

Whilst upgrading a public web site that I had previously created in SharePoint 2007, during testing I noticed this strange number appearing at the end of my upgraded search results page. After the last result I was seeing a number like 68050. This number changed as I performed more searches.
I hadn't touched my custom search results XSLT at all during the upgrade, so I was wondering why this number started appearing. To troubleshoot, I first edited the search results page and changed the XSLT so that I could see the Search Results XML. The XSLT looked like:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>
<xsl:template match="/">
<xmp><xsl:copy-of select="*"/></xmp>
</xsl:template>
</xsl:stylesheet>

This revealed to me 2 new elements right before the end of the </all_results> tag. The extra elements were 'totalresults' and 'numberofresults'.

As SharePoint 2010 now uses Federated Search Locations with custom XSLT allocated to each location, I decided to look to see what the OOB 'Local Search Results' location was doing. Turns out that it now includes a couple of extra XSLT templates:

<xsl:template match="TotalResults">
</xsl:template>
<xsl:template match="NumberOfResults">
</xsl:template>

So I added these to extra XSLT templates into my custom XSLT and voila! No more strange number at the end of my search results.

What to do when Content Deployment fails

I had to help out some guys from Accenture today with the setup of content deployment for a global SharePoint 2010 Internet site. Basically the first content deployment from the Authoring to Production environment didn't send across all of the published pages. As a result, settings like 'Welcome Page' were lost. Further content deployments did not seem to help or fix what was previously broken. As SharePoint's content deployment is incremental by default (UI) I created a full content deployment job through PowerShell, but then we started seeing the error 'Unable to import folder _catalogs/masterpage/Forms/Page Layout. There is already an object with the Id in the database from another site collection'.

I used my friend Google and found this, which helped me solve the problem.

So it seems that information about what has been deployed before is not contained within the Authoring environment, but the destination environment, and deleting the site collection and re-creating it with an empty template doesn't help. In my case I deleted the web application entirely and re-created it through script. In the article, you can also detach and re-attach the content database through Central Admin.

Fixing the Health Analyzer SPTraceV4 issue

Within a SharePoint farm configuration (multiple servers), the SharePoint Health Analyzer will first complain that the SPTraceV4 account should not be running as a local service. If you manually fix this by setting a domain account for the trace service (on each server) and restarting the service, sometimes you will still get the message 'Built-in accounts are used as application pool or service identities' within the Health Analyzer. To fix this, do the following:

1) Create the Trace Account (e.g. DOMAIN\svc-SP_TRC) as a managed account.
2) Start up the SharePoint 2010 Management Shell in administrator mode
3) Type the following Powershell script:

$servicename = "SPTraceV4"
$managedaccountname = "DOMAIN\svc-SP_TRC"
$farm = Get-SPFarm
$SPTimerv4 = $farm.Services | Where {$_.Name -eq $servicename}
$SPTimerV4NewAccount = Get-SPManagedAccount $managedaccountname
$SPTimerv4.ProcessIdentity.CurrentIdentityType = "SpecificUser"
$SPTimerv4.ProcessIdentity.ManagedAccount = $SPTimerV4NewAccount
$SPTimerv4.ProcessIdentity.Update()

4) Goto to each server in the farm and restart the tracing service. Then do an IISRESET /noforce on each SharePoint Server
5) Open up Central Administration, view the problem report and re-analyze the built-in accounts Health Analyzer message.
6) Close the report message and refresh the page. The error should now be gone.
7) If you have moved your logs to another (e.g. non-System) drive, on the directory where logs are to be written to, ensure that the nominated domain Trace account has full read/write permissions to it. You may have to restart the trace service and do an IISRESET again to notice that activity is now being written to the LOGS directory. Note that this approach also fixes the issue where you see lots of log file entries, all 0KB in length.