Could not get SPWeb so could not get user key.

We were seeing the following errors in the ULS during a search crawl using a custom content enrichment web service (CEWS). Unexpected: "Could not get SPWeb so could not get user key." Medium: "No user key for user in request usage." Our CEWS was running in an anonymously accessible site in a specific web application for our search center. The search center web application was running on legacy Windows authentication. The content we were indexing was in a different web application that was running on Claims authentication. The solution to our problem was convert our search center web application to Claims as well. This can easily be done using PowerShell: Convert-SPWebApplication -Identity [web application] -From Legacy -To Claims

Invalid object name 'dbo.ECMUsage'

After attaching (restoring) our SharePoint 2010 Managed Metadata service application database to our SharePoint 2016 beta 1 development environment, upgrading the database schema failed. This resulted in a partially working service application with occasional "Operation failed..." messages.

Checking the Databases Upgrade status (Upgrade and Migration > Review database status) stated the following for our Managed Metadata database:
Database is in compatibility range and upgrade is recommended.

Checking the Upgrade status (Upgrade and Migration > Check upgrade status) pointed me to an upgrade logfile. This file contained the following error messages:

ERROR Action 16.0.9.0 of Microsoft.SharePoint.Taxonomy.Upgrade.TaxonomyDatabaseSequence failed. 46e6529d-376c-8084-2d87-feca3cee9bb5
ERROR Exception: Invalid object name 'dbo.ECMUsage'. 46e6529d-376c-8084-2d87-feca3cee9bb5
ERROR   at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)     at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)     at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)     at System.Data.SqlClient.SqlCommand.RunExecuteNonQueryTds(String methodName, Boolean async, Int32 timeout, Boolean asyncWrite)     at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(TaskCompletionSource`1 completion, String methodName, Boolean sendToPipe, Int32 timeout, Boolean asyncWrite)     at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()     at Microsoft.Office.Server.Data.SqlSession.ExecuteScript(TextReader textReader, Int32 commandTimeout)     at Microsoft.SharePoint.Upgrade.SPDatabaseAction.ExecuteSql(String sql, Int32 commandTimeout)     at Microsoft.SharePoint.Taxonomy.Upgrade.TaxonomyDatabaseAction_16_0_9_0.Upgrade()     at Microsoft.SharePoint.Upgrade.SPActionSequence.Upgrade() 46e6529d-376c-8084-2d87-feca3cee9bb5

Apparently, upgrading from schema version 14.0.10.0 to target schema version = 16.0.10.0 didn't go so well on my SharePoint 2016 environment. The biggest issue seems to be the missing table "ECMUsage", which should be added to the schema somewhere along the upgrade way.

Solution
Upgrade the Managed Metadata service application database on a SharePoint 2013 environment first. This will add the ECMUsage table and prepare the database for the upgrade on the SharePoint 2016 beta 1 environment.

In short, the upgrade from the Managed Metadata service application from SharePoint 2010 to SharePoint 2016 (beta 1) is as follows:

1. On SharePoint 2010, mark MM database as read-only and make back-up
2. On SharePoint 2013, restore the SharePoint 2010 MM database back-up and unmark as read-only
3. On SharePoint 2013, create a new MM service application (using PowerShell) pointing to the restored DB. This will upgrade the MM database to the 2013 schema.
4. On SharePoint 2013, mark MM database as read-only and make back-up
5. On SharePoint 2016 (beta 1), restore the SharePoint 2013 MM database back-up and unmark as read-only
6. On SharePoint 2016 (beta 1), create a new MM service application (using PowerShell) pointing to the restored DB. This will also upgrade the MM database to the latest 2016 (beta 1) schema.

More details regarding the exact upgrade steps can be found on TechNet:

https://technet.microsoft.com/en-us/library/jj839719.aspx

Cheers.

FASTMaxNumberOfFilters

The case

You either run into this issue in the ULS log:
12/06/2012 13:34:27.23 w3wp.exe (0x2E30) 0x35D0 SharePoint Server Search Query dn1p Medium Filter category FASTMaxNumberOfFilters in the config is in wrong format.Input string was not in a correct format. 20932873-e591-4a68-ba36-7541401c2fea
...or you face a problem like this:

You're using FAST Search Server 2010 for SharePoint and you want to remove the limit of filters returned for a single refiner. Unfortunately you're unable to do so using the MaxNumberOfFilters property of the Category element in the configuration of the Refinement web part.

The problem

Somehow, FAST ignores the setting of MaxNumberOfFilters, or at least it ignores the value of '0' which, according to MSDN should tell SharePoint/FAST to return all filters, and not just a maximum of n.

The solution

There appears to be an undocumented attribute to the Category element called FASTMaxNumberOfFilters. I don't know why this isn't documented, but if you're using FAST it's the one to use instead of MaxNumberOfFilters. I came across this fact when I wanted my refiner to show all available filters (over 500) and it was somehow capped at 100, even though I had MaxNumberOfFilters set to 0. I had several ULS Log-errors stating that FASTMaxNumberOfFilters was not provided in the correct format, which triggered me to look further into this.
Setting FASTMaxNumberOfFilters to 0 won't be interpreted as "show all". Instead, you have to provide a positive number. In my case, I used 10000 and after that I correctly got my 500+ values instead of 100.

Example:

<Category Title="Sources" Description="The source of the document" Type="Microsoft.Office.Server.Search.WebControls.ManagedPropertyFilterGenerator" MetadataThreshold="1" NumberOfFiltersToDisplay="0" MaxNumberOfFilters="0" FASTMaxNumberOfFilters="10000" ShowMoreLink="True" MappedProperty="contentsource" MoreLinkText="show more" LessLinkText="show less" ShowCounts="Count" />

Remove crawled properties in FAST

Unfortunately, there's no PowerShell-command to delete/remove a single crawled property in FAST (nor is there one in SharePoint, as is stated by Corey Roth). In most cases, there's no need for such a command. However, when you're "experimenting" in a development environment, the list of debug/test/dummy crawled properties might become very long and the need to clean up the place might arise. It would've been nice if Microsoft offered the Remove-FASTSearchMetadataCrawledProperty command, in addition to the already available Get-, New-, Set- commands, but sadly, we'll have to do without this.

There is, however, a way to get rid of all unused/unmapped crawled properties all at once. You can either do this through the UI in Central Administration. Just go to your FAST Query Service Application > FAST Search Administration > Crawled Property Categories > [category-that-needs-cleaning] > Edit Category > Check "Delete all unmapped crawled properties" > Hit OK:

If you're more into scripting your configuration/deployment, there's also a nice way to do this through PowerShell. Just start up your FAST Search Server 2010 for SharePoint PowerShell window and run:

$category = Get-FASTSearchMetadataCategory -Name "[category-that-needs-cleaning]"
$category.DeleteUnmappedProperties()

FAST Search Server 2010 for SharePoint versions/build numbers

I couldn't find a nice short list of FAST Search versions/build numbers elsewhere so decided to write it down myself.

These are the different build numbers that are available for FAST Search Server 2010 for SharePoint (UPDATED 2013-02-13):

Build number	Description	Information	Download
14.0.4763.1000	RTM
14.0.5128.5001	October 2010 CU	KB2449730	Download
14.0.5136.5000	February 2011 CU	KB2504136	Download
14.0.6029.1000	Service Pack 1	KB2460039	Download
14.0.6109.5000	August 2011 CU	KB2553040	Download
14.0.6117.5002	February 2012 CU	KB2597131	Download
14.0.6120.5000	April 2012 CU	KB2598329	Download
14.0.6126.5000	August 2012 CU	KB2687489	Download

To check the installed version of FAST Search, go to "Programs and Features" and look for the "Microsoft FAST Search Server 2010 for SharePoint":

FAST & SharePoint Developer Tools

This is mainly a reference list for myself for when I start using a new development VM. It's a list of urls to tools I use often while developing for SharePoint (2010).

General tools

• 7-zip http://7-zip.org/
• Notepad++ http://notepad-plus-plus.org/
• JSMinNpp Javascript plugin http://sourceforge.net/projects/jsminnpp/
• WinMerge http://winmerge.org/
• ILSpy (open source alternative to .NET Reflector) http://wiki.sharpdevelop.net/ilspy.ashx
• Fiddler http://www.fiddler2.com/ 
• Virtual CloneDrive (ISO Mounting Software) http://www.slysoft.com/nl/virtual-clonedrive.html

SharePoint specific tools

• SharePoint 2010 Manager http://spm.codeplex.com/
• ULS Viewer http://archive.msdn.microsoft.com/ULSViewer/
• SPDisposeChecker http://archive.msdn.microsoft.com/SPDisposeCheck 
• Steve Peschka Search Explorer http://blogs.technet.com/b/speschka/archive/2010/08/15/free-developer-search-tool-for-sharepoint-2010-search-and-fast-search-for-sharepoint.aspx

FAST Search 2010 for SharePoint specific tools

• FAST Search for SharePoint Query Tool http://fastforsharepoint.codeplex.com/
• FAST Search for SharePoint Query Logger http://fs4splogger.codeplex.com/

Office 365 specific tools

• Office365 Sandbox FxCop rules http://o365fxcoprules.codeplex.com/
• 
  

PowerShell specific tools

• PowerGUI http://powergui.org/
•  

 This list is probably never complete, so I will update it whenever I think something's missing!

"The local farm is not accessible."-error

I came across the following error message when I was trying to do some powershell configuration on my FAST Search for SharePoint 2010 setup:

"The local farm is not accessible. Cmdlets with FeatureDependencyId are not registered."

At first I ignored this message, but when I tried to do some configuration using the Get-SPEnterpriseSearchExtendedQueryProperty cmdlet I got the following error, indicating the this cmdlet wasn't registered:

Apparently, this cmdlet is one that runs on farm level.

I didn't understand why my farm wasn't accessible, since I was running this powershell script on the SharePoint server itself as a farm administrator. I checked the event log (14Hive\LOGS) and found out I didn't have sufficient rights on the SharePoint configuration database:

01/05/2010 08:58:28.03     PowerShell.exe (0x2618)                     0x10F4    SharePoint Foundation             Database                          880j    High        SqlError: 'Login failed for user 'DEMO\mark'.'    Source: '.Net SqlClient Data Provider' Number: 18456 State: 1 Class: 14 Procedure: '' LineNumber: 65536 Server: 'sql'     
01/05/2010 08:58:28.03     PowerShell.exe (0x2618)                     0x10F4    SharePoint Foundation             Database                          3351    Critical    SQL database login for 'SharePoint_Config_SP2010DEMO' on instance 'sql' failed. Additional error information from SQL Server is included below.  Login failed for user 'DEMO\mark'.     

When I made sure my account had sufficient rights, the problem was solved!

I guess this problem can pop-up in other occasions as well, so my advice is to check the log as soon as you encounter similar problems!

Howto: Disable SharePoint's double postback block

I was working on a SharePoint web part today when I came across a very annoying issue.

The idea of my web part was quite simple:

- Display a form with various fields and a "Generate Report" button
- When a user clicks the "Generate Report" button, a Word-file is dynamically created and made available for download.

The button is a common asp:Button control:
<asp:Button runat="server" id="CreateReport" Onclick="CreateReport_Click" text="Create Report">

The event handler is also quite simple:
protected void CreateRapport_Click(object sender, EventArgs e)
{
  PersistFieldValues();
  Response.Redirect("/_layouts/MyProject/GenerateWordReport.ashx");
}

The PersistFieldValues() method stores all form field values in a Session variable. These values are then used by the GenerateWordReport web handler to generate a Word file.
 
The user is redirected to the web handler which generates a Word file dynamically and uses the following header information to make sure the user gets the proper "Open/Save As/Cancel" dialog for the document:
response.AddHeader("Content-Disposition", "attachment; filename=Report.doc");
response.ContentType = "application/ms-word";

The user can now open the document, but in the back the original web form is still being presented in the browser, without having been refreshed. This is caused by the fact that a redirect has been done to the HttpHandler which sent binary content to the browser. 
 
Unfortunately, the form is no longer responsive, it's dead. You can no longer press buttons or any other links that cause a postback. This behavior is caused by the fact that as soon as you do a postback to the server, SharePoint makes sure in Javascript that you can't submit the same form twice.
 
At first I thought this was an asp.net issue, but after spending an awful lot of time on Google I finally found out asp.net wasn't the source of my problem, SharePoint was. The following discussion provided me with a good solution for my problem: http://www.telerik.com/community/forums/aspnet-ajax/grid/export-to-excel-in-sharepoint-application-page.aspx
 
The solution I implemented
In the webpart, I rendered a small piece of Javascript that avoids SharePoint from blocking multiple postbacks:

if (!Page.ClientScript.IsStartupScriptRegistered("SUPPRESSSUBMITWRAPPER"))
{
  Page.ClientScript.RegisterStartupScript(this.GetType(),
  "SUPPRESSSUBMITWRAPPER",
  @"
_spBodyOnLoadFunctionNames.push(""SuppressSubmitWrapper"");
function SuppressSubmitWrapper()
{
  _spSuppressFormOnSubmitWrapper = true;
}
",
true);
}