Unexpected error when creating Fast Search Center

I was having a frustrating problem recently with a brand new site collection in SharePoint 2010.  Each time I attempted to create a new FAST Search Centre site an unexpected error would quickly occur with a different correlation ID each time.

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.

 

 

 

 

 

 

SharePoint 2010 – Enable refiner web part counts

There is a useful attribute which can be added the the SharePoint 2010 Refiner web part XML to display the document counts.

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

Accessing the Global Assembly Cache using Windows Explorer

Accessing the Global Assembly Cache using Windows Explorer

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

SharePoint object model updates not triggering workflow

A situation I have observed a number of times while working with the SharePoint object model is that workflows don’t appear to be triggered on update calls.

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

Search Core Results Web Part – How to view raw XML

Sometimes when working with the Search Core Results web part within SharePoint it may be useful to see all of the XML that is being returned to the XSL stylesheet.

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

Managed Metadata Service – The required feature is not enabled for this column type

I was recently attempting to add a new managed metadata type site column to an existing SharePoint 2010 site collection but when I tried to select a term set I saw the following error:

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

Access denied – Microsoft loopback security check

I recently experienced an issue with a server which had me scratching my head for a couple of hours.  Fortunately my colleague had previously experienced this issue and promptly directed me to a Microsoft KB which allowed me to resolve the issue.

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

The crawl rules may have to be modified to include this address. (0x80040d07)

I was recently reminded of a problem I had previously experienced but subsequently forgotten with regard to MOSS content crawling.

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.

SharePoint 2010 anonymous access

To enable anonymous access in SharePoint 2010 the following steps will need to be completed.

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.

The search request was unable to connect to the Search Service

I had an issue on a SharePoint 2007 server recently that wasn’t immediately obvious to me (it may well have been obvious to you however).

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!