This new site collection was in a web application with other site collections where the FAST Search Center sites had been sucessfully created.

After attempting to create the FAST Search Center site several times without success and with very little useful information in the event logs I turned to Google and found the folowing blog post with some useful advice:

http://www.dotnetmafia.com/blogs/dotnettipoftheday/archive/2011/04/12/an-unexpected-error-has-occurred-when-creating-an-enterprise-search-center-site.aspx

The problem was because I had not enabled the ‘SharePoint Server Publishing Infrastructure site collection feature.

Once this feature was enabled I was able to create the FAST Search Center site successfully.  It was a quick fix but if I had not found the above blog post it could have taken me much longer to get to the bottom of the issue.

The typical XML for a refiner category looks something like this:

<Category
Title=”Managed Metadata Columns”
Description=”Managed metadata of the documents”
Type=”Microsoft.Office.Server.Search.WebControls.TaxonomyFilterGenerator”
MetadataThreshold=”1″
NumberOfFiltersToDisplay=”6″
MaxNumberOfFilters=”20″
ShowMoreLink=”True”
MappedProperty=”ows_MetadataFacetInfo”
MoreLinkText=”show more”
LessLinkText=”show fewer”/>

In order to display the count next to the refiner it is simply a case of adding the ShowCounts attribute.  The count can be displayed as a a traditional item count or a percentage by specifying either Count or Percentage as the value of the ShowCounts attribute.

<Category
Title=”Managed Metadata Columns”
Description=”Managed metadata of the documents”
Type=”Microsoft.Office.Server.Search.WebControls.TaxonomyFilterGenerator”
MetadataThreshold=”1″
NumberOfFiltersToDisplay=”6″
MaxNumberOfFilters=”20″
ShowMoreLink=”True”
MappedProperty=”ows_MetadataFacetInfo”
MoreLinkText=”show more”
LessLinkText=”show fewer”
ShowCounts=”Count”/>

Now counts will appear next to the managed metadata fields (in this example) but the same property can be used for any refiner category.

More Info
http://msdn.microsoft.com/en-us/library/ff625183.aspx

This is something I have to look up every time I need to do it as I always managed to forget, so I thought it may be something that is useful to other users.

By default it is not possible to browse the physical DLLs held within the GAC (Global Assembly Cache) using Windows Explorer as it automatically uses the built in Assembly Cache Viewer to display a view of the installed assemblies along with their version, culture, token and architecture information. You don’t get to see the actual folder structure contained within it.

If you want to see the actual folders with in the assembly or access the physical DLL files then there are a couple of different methods to achieve this but the easiest by far (in my opinion) is to simply run the following command at the command prompt to map a drive to the GAC (NOTE: replace [X] with the drive letter you wish to use for browsing your GAC folder):

SUBST [X]: “C:\Windows\assembly”

i.e.

SUBST Z: “C:\Windows\assembly”

The SUBST DOS command allows a drive letter to be mapped to a physical path and this will provide access to the contents of the assembly by browsing to the drive letter we selected, in this instance drive Z:\.

When accessing the newly mapped drive you will be presented with a selection of folders and you will be able to browse for the specific DLL of interest. The location will depend on the name of the assembly and whether it is an x86 or x64 DLL but it should be easy enough to location using this method.

You will now have full access to all of the physical DLLs held in the cache which can be useful in a number of situations.

More info:
http://en.wikipedia.org/wiki/Subst

In the past I have worked around this issue by simply adding some code to loop through the registered workflow items and manually triggering them which has always solved the problem.

I have read recently that the reason the workflow fails to run is due to it being run on a separate thread and that quitting the web app/console app before the asynchronous workflow threads have finished causes them to abort and from the end users perspective the workflow appears not to have run.  This is a known bug in SharePoint but there are a number of workarounds so it’s not considered a show stopper.

It is however possible to work around this limitation by calling SPSite.WorkFlowManager.Dispose() after the item update.  This will wait for the workflow threads to complete before exiting.

Some useful links for further information:
http://blogs.msdn.com/b/malag/archive/2008/07/11/splistitem-update-not-starting-workflow.aspx
https://blogs.blackmarble.co.uk/blogs/rhepworth/archive/2008/07/14/workflow-and-sql-error-update.aspx

It is possible to see the raw XML by replacing the XSL stylesheet with the following XSL (be sure to back-up the existing stylesheet first, if it has been modified):

<?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 can be modified by editing the Search Core Results web part properties.  The XSL Editor is listed under the Display Properties heading.

Search Core Results web part screen shot

These MSDN links may be useful for further information:
How to: View Search Results XML Data
How to: Change the Properties Returned in the Core Search Results

The required feature is not enabled for this column type

This had me a little confused.  I checked all of the features against another SharePoint 2010 server that was working as expected and everything appeared to be the same.

A search on Google revealed that there are actually some features that are not listed in the site features or site collection features that can (somehow) become disabled and will then need to be manually activated using STSADM.

STSADM -o activatefeature -id 73EF14B1-13A9-416B-A9B5-ECECA2B0604C -url http://sitecollection -force

These links were very helpful:
http://dotneteers.net/blogs/aghy/archive/2010/03/14/activating-managed-metadata-feature-on-your-web-application-in-sharepoint-2010.aspx

http://jasonlochan.blogspot.com/2010/04/managed-metadata-service-required.html

In Windows 2003 SP1 and above (IIS 5.1+) Microsoft built a new security feature into IIS to prevent reflection attacks.  This feature looks at the FQDN or custom host header being used and if it differs from the local machine name you may receive access denied or unauthorised errors when services call themselves locally.

With regard to SharePoint problems can surface with indexer access issues or any web service calls to the local machine.

There are a couple of fixes available (which are described in the Microsoft KB linked below) and both involve registry updates:

Method 1: Specify host names (Preferred method if NTLM authentication is desired)
Method 2: Disable the loopback check (less-recommended method)

I chose the second option for brevity (but this may not be the best option for your situation).  Before making any changes to the registry it is worth taking a moment to back it up.

In order to disable the loopback check a DWORD key named DisableLoopbackCheck with a value of 1  must be added to the following registry path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

Restart the IIS Admin Service (a reboot may be required before these changes take effect) and the new settings should be in place.  With the loopback check disabled the FQDN or custom host header no longer causes a problem.

Take a look here for more detailed information from Microsoft:
http://support.microsoft.com/kb/896861

In this particular instance I was using a custom protocol handler but I believe this issue will apply to the OOTB MOSS Search functionality as well.  I was attempting to crawl a file share using a custom protocol handler and kept receiving a myriad of misleading error messages in the application event log, including:

The specified address was excluded from the index. The crawl rules may have to be modified to include this address.   (0x80040d07)

as well as:

The update cannot be started because all of the content sources were excluded by crawl rules, or removed from the index configuration.

It turns out that if the Office SharePoint Server Search windows service credentials are changed this corrupts the password of the default content access account being used by the SharePoint search SSP.

To resolve this issue I went to SharePoint Central Administration > Search SSP (i.e. SharedServices1 etc) > Search administration > Default content access account and re-entered the crawling account password.

After doing this everything was peachy, no more errors in the event log.

It may look like there is a lot of steps to follow but it will only take a couple of minutes to complete and is actually very simple once you have learned the location of the required ribbon buttons:

1. Go to the Central Administration web application.
2. Select the Manage Web Applications option from the Application Management category.
3. Highlight the web application you wish you enable anonymous access on (i.e. SharePoint – 80) by clicking on the application row from the list but being careful not to click on the link text.  This will enable a number of new options on the ribbon bar.
4. From the ribbon bar choose the Authentication Providers button.
5. From the modal dialog pop-up check the Enable anonymous access option and hit the save button.
6. Now choose the Anonymous Policy ribbon button.
7. From the modal pop-up select the required zone and ensure that the Permissions are set to None and hit the save button.
8. Now browse to the root Site Collection of the web application to have anonymous access enabled.
9. Select Site Settings from the Site Actions drop down menu.
10. Select the Site Permissions link from the Users and Permissions category.
11. From the ribbon choose the Anonymous Access button.
12. From the modal pop-up select the level of anonymous action to be granted (i.e. Entire Web site) and hit the OK button to save.

Anonymous access should now be enabled.

Whenever searching using the Microsoft Search product the following error would be returned immediately:

The search request was unable to connect to the Search Service

After a little bit of head scratching, checking options in Shared Services and checking of Application Poole accounts I was looking at the list of services in Windows Service Manager and noticed that the Office SharePoint Server Search service had stopped (unbeknown to me).  Restating this service fixed the issue immediately.

Happy days!