Modern Search Results and file shares

September 25, 2020 - 10:30, by Steven Van de Craen - 0 Comments

In an hybrid search environment the Cloud Search Service Application indexes local file shares and ships the index to SharePoint Online for querying. If you are indexing a local file share then you’ll notice something funny with those search results in Modern Search in SharePoint Online.


As you see the Modern Search just renders the result as non-clickable. Now you could still use Classic Search, but then it would get blocked if you click on it in a modern browser (which you should) due to security concerns.


Not allowed to load local resource: file://myserver/testfileshare/test.txt


The first issue (the visualisation in Modern Search) could be handled by using your own Modern Search results, for example via the PnP Modern Search Solution or use classic search result pages, so I’m not digging into this. The second issue however is generic and requires some thought.


I have seen environments that link directly to file servers for content and ideally that content would be moved into the environment. But there are still valid reasons for file shares and organisations may want to expose them to users through search. So for those cases you would need to find a solution. Here’s what I came up with…

  1. Use Internet Explorer; ugh. I can’t recommend this anymore but since it technically solves the issue so I’m adding it to the list.
  2. Start the browser with a flag to allow loading local resources (eg Chrome used to have --allow-file-access-from-files but this no longer works); it cannot be enforced for external users (if applicable) and it doesn’t feel like the right approach.
  3. Use a browser extension; there are browser extensions that restore the functionality when clicking on a file:// link. The issue I have with extensions is are they safe and trustworthy?
  4. Use Microsoft Edge IE Mode; users still use a modern browser but specific sites will use the IEMode. It would be a shame to have your entire “modern” SharePoint Online environment to run in IE Mode, no? Also it cannot be enforced for external users (if applicable)
  5. Put a web server or application in front of the file share; it shows the directory and file structure of the file share with authentication to ensure results are properly shielded
  6. If you have any other suggestions or solutions feel free to let me know


So let’s go with number 5 on the list. Now I want to have my search results coming from the application.

  1. Either the application supports being crawled directly as a website by SharePoint Search, and you just configure the Content Sources as such
  2. Or it may be possible to configure Server Name Mappings to transform the original file share UNC path
    Run  crawl and voila the search results are transformed into a web url


In either case your search results would now be coming from a web application and you won’t have the issue anymore.

So, what’s your take on this?

SharePoint Server Search and TIF file indexing

November 23, 2018 - 16:30, by Steven Van de Craen - 0 Comments

A client who was using TIF files in SharePoint 2016 reported that the search results didn’t link to the file directly, but rather to the List Item Display Form (DispForm.aspx?ID=x) for these files and wanted that changed.

Most info on the web on how to configure for TIF file indexing is rather outdated and incomplete so here’s an update for SharePoint 2016 and 2019.


1. Enable the TIFF iFilter on all servers configured for “Content Processing” in the Search Topology

Install-WindowsFeature -Name "Windows-TIFF-IFilter"


2. [Windows Server 2012 (R2) only] Enable the Windows Search Service Feature on all servers configured for “Content Processing” in the Search Topology

Install-WindowsFeature -Name "Search-Service"


3. Add both tif and tiff to the list of Crawled File Types for the Search Service Application

Add to Crawled File Types


4. Add both tif and tiff as a file format to the Search Service Application

$ssa = Get-SPEnterpriseSearchServiceApplication

New-SPEnterpriseSearchFileFormat -SearchApplication $ssa tif "TIFF Image File" "image/tiff"

New-SPEnterpriseSearchFileFormat -SearchApplication $ssa tiff "TIFF Image File" "image/tiff"


5. Restart the SharePoint Search Host Controller on all servers configured for “Content Processing” in the Search Topology

Restart-Service SPSearchHostController


6. Run a Full Crawl


You should now have proper indexing of TIF files.

Crawl Log

TIF search result

SharePoint 2013: Programmatically set crawl cookies for forms authenticated web sites

August 29, 2015 - 07:54, by Steven Van de Craen - 0 Comments

Last week I was having difficulties in crawling forms authenticated web sites. When configuring a crawl rule to store the authentication cookies the login page was returning multiple cookies with same name but different domain.

Add Crawl Rule

This gave issues in a later stage (during crawl) because all cookies would be sent along with the request, the target system had issues correctly identifying us due to these “duplicate” cookies.

You can easily check the request information that is sent during crawl by starting fiddler on the crawl server and configuring the proxy settings to http://localhost:8888 (default Fiddler settings).

 Search Proxy Setting

In the end we chose for an alternate method of configuring the cookies, namely through PowerShell. This gave us the ultimate flexibility to configure exactly the cookies we wanted to pass along with the crawl requests.

asnp microsoft.sharepoint.powershell -ea 0 | Out-Null $ssa = get-spenterprisesearchserviceapplication $crPath = 'http://authenticatedwebsite*' # Get or create crawl rule $cr = Get-SPEnterpriseSearchCrawlRule -SearchApplication $ssa | ? { $_.Path -eq $crPath } if ($cr -eq $null) { $cr = New-SPEnterpriseSearchCrawlRule -Path $crPath -SearchApplication $ssa -Type InclusionRule -AuthenticationType CookieRuleAccess -FollowComplexUrls $true } # Set cookie credentials $cr.SetCredentials('CookieRuleAccess', 'myUser=crawlUser; myPwd=crawlPassword', 'http://cookie-set-via-powershell')


SharePoint 2013: Some observations on Enterprise Search

August 13, 2015 - 16:44, by Steven Van de Craen - 0 Comments

I’m doing some testing with the Enterprise Search in SharePoint 2013 for a customer scenario and here are some observations…

Content Source as Crawled Property

The “Content Source” name is out of the box available as Managed Property on all content in the search index

This makes it possible to create Result Sources that aggregate content from different Content Sources similar to Search Scopes back in the old days.

SharePoint 2013 Search Query Tool #1

Meta elements (HTML <meta> tags) as Crawled Properties

Information from meta elements in web pages is extracted into crawled properties

Consider the following example:

Simple website with meta tags

After crawling this website with SharePoint 2013 Search it will create (if new) or use (if existing) a Crawled Property and store the content from the meta element. The Crawled Property can then be mapped to Managed Properties to return, filter or sort query results.

SharePoint 2013 Search Query Tool #2

Query string parameters as Crawled Properties

Query string parameters are not extracted into Crawled Properties

This was actually a request from the customer in order to be able to provide additional information regarding documents (on their website) into the search index. As I suspected it isn’t possible out of the box but you could definitely do it using Content Enrichment.

The “OriginalPath” is available as an input property for Content Enrichment and contains the exact url used for indexing the document:

Content Enrichment Input Properties

With Content Enrichment it is pretty straightforward to look for predefined query string parameters and then map them to output properties.

$ssa = Get-SPEnterpriseSearchServiceApplication $config = New-SPEnterpriseSearchContentEnrichmentConfiguration $config.Endpoint = 'http://cews:818/ContentEnrichmentService2.svc' $config.InputProperties = 'OriginalPath', 'ContentSource' $config.OutputProperties = 'MyParam1', 'MyParam2' $config.DebugMode = $false $config.SendRawData = $false Set-SPEnterpriseSearchContentEnrichmentConfiguration –SearchApplication $ssa –ContentEnrichmentConfiguration $config

More information on Content Enrichment from my SharePoint Saturday presentation:


SharePoint Saturday Belgium 2014 - Content Enrichment in SharePoint Search

April 28, 2014 - 15:06, by Steven Van de Craen - 0 Comments

Last Saturday I delivered a session on “Content Enrichment in SharePoint Search” on the Belgian SharePoint Saturday 2014, showing how to configure it, its potential and some development tips and tricks. Although it was a very specific and narrow topic there was a big audience for it. We even had to bring in extra chairs to have everyone seated.

If you missed my session (shame on you!) or you want to read up on it again, below is my deck and demo code.


SPSBE 2014 Content Enrichment in SharePoint Search



The demos showed the basic configuration, how to use WCF Routing to overcome the biggest limitation, how to debug using Fiddler by configuring the proxy, how to debug by attaching to the noderunner process, etc. The final demo would extract bank account numbers from indexed documents and store them in dedicated Managed Properties to increase findability when searching on one of these numbers.


Disclaimer: you’re free to use this code as you desire, but I’m not taking responsibility should it blow up your server or make babies cry.


Community Red heart

I think we can all agree that SPSBE2014 was a huge success. A big applause for the organisers, the speakers and the attendees for making it all happen. It goes to show that the our SharePoint Community is really great, so show them some love on or

SharePoint 2013 search open in client

March 26, 2014 - 16:26, by Steven Van de Craen - 1 Comments


SharePoint 2013 search results uses Excel Calculation Services to open workbooks found in the search results, despite having "open in client" specified on the Document Library and/or the Site Collection level. Notice the URL pointing to _layouts/xlviewer.aspx at the bottom of the screen. In this scenario I only have SharePoint Server 2013 installed without any Office Web Apps servers.
Searching a workbook


Initial solution

In my previous encounter with this issue I used a custom Search Result Type with Display Template in order to control the link that is rendered for the search result item.


<html xmlns:mso="urn:schemas-microsoft-com:office:office" xmlns:msdt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882"> 
<title>Excel Client Item</title>

<!--[if gte mso 9]><xml>
<mso:TemplateHidden msdt:dt="string">0</mso:TemplateHidden>
<mso:MasterPageDescription msdt:dt="string">Displays a result tailored for Microsoft Excel documents.</mso:MasterPageDescription>
<mso:ContentTypeId msdt:dt="string">0x0101002039C03B61C64EC4A04F5361F385106603</mso:ContentTypeId>
<mso:TargetControlType msdt:dt="string">;#SearchResults;#</mso:TargetControlType>
<mso:HtmlDesignAssociated msdt:dt="string">1</mso:HtmlDesignAssociated>
<mso:ManagedPropertyMapping msdt:dt="string">'Title':'Title','Path':'Path','Description':'Description','EditorOWSUSER':'EditorOWSUSER','LastModifiedTime':'LastModifiedTime','CollapsingStatus':'CollapsingStatus','DocId':'DocId','HitHighlightedSummary':'HitHighlightedSummary','HitHighlightedProperties':'HitHighlightedProperties','FileExtension':'FileExtension','ViewsLifeTime':'ViewsLifeTime','ParentLink':'ParentLink','FileType':'FileType','IsContainer':'IsContainer','ServerRedirectedURL':'ServerRedirectedURL','ServerRedirectedEmbedURL':'ServerRedirectedEmbedURL','ServerRedirectedPreviewURL':'ServerRedirectedPreviewURL'</mso:ManagedPropertyMapping>
    <div id="Item_Excel_Client">
        if(!$isNull(ctx.CurrentItem) && !$isNull(ctx.ClientControl)){
            var id = ctx.ClientControl.get_nextUniqueId();
            var itemId = id + Srch.U.Ids.item;
            var hoverId = id + Srch.U.Ids.hover;
            var hoverUrl = "~sitecollection/_catalogs/masterpage/Display Templates/Search/Item_Excel_HoverPanel.js";
            $setResultItem(itemId, ctx.CurrentItem);
            ctx.CurrentItem.csr_Icon = Srch.U.getIconUrlByFileExtension(ctx.CurrentItem);
            ctx.CurrentItem.csr_OpenApp = "excel";
            ctx.CurrentItem.csr_Path = ctx.CurrentItem.Path;
            ctx.currentItem_ShowHoverPanelCallback = Srch.U.getShowHoverPanelCallback(itemId, hoverId, hoverUrl);
            ctx.currentItem_HideHoverPanelCallback = Srch.U.getHideHoverPanelCallback();
            <div id="_#= $htmlEncode(itemId) =#_" name="Item" data-displaytemplate="ExcelItem" class="ms-srch-item" onmouseover="_#= ctx.currentItem_ShowHoverPanelCallback =#_" onmouseout="_#= ctx.currentItem_HideHoverPanelCallback =#_">
                <div id="_#= $htmlEncode(hoverId) =#_" class="ms-srch-hover-outerContainer"></div>


/* This file is currently associated to an HTML file of the same name and is drawing content from it.  Until the files are disassociated, you will not be able to move, delete, rename, or make any other changes to this file. */

function DisplayTemplate_89a1689efe684e93be8c5bdaa1e46b07(ctx) {
  var ms_outHtml=[];
  var cachePreviousTemplateData = ctx['DisplayTemplateData'];
  ctx['DisplayTemplateData'] = new Object();
  DisplayTemplate_89a1689efe684e93be8c5bdaa1e46b07.DisplayTemplateData = ctx['DisplayTemplateData'];

  ctx['DisplayTemplateData']['TemplateUrl']='~sitecollection\u002f_catalogs\u002fmasterpage\u002fDisplay Templates\u002fSearch\u002fItem_Excel_Client.js';
  this.DisplayTemplateData = ctx['DisplayTemplateData'];

  ctx['DisplayTemplateData']['ManagedPropertyMapping']={'Title':['Title'], 'Path':['Path'], 'Description':['Description'], 'EditorOWSUSER':['EditorOWSUSER'], 'LastModifiedTime':['LastModifiedTime'], 'CollapsingStatus':['CollapsingStatus'], 'DocId':['DocId'], 'HitHighlightedSummary':['HitHighlightedSummary'], 'HitHighlightedProperties':['HitHighlightedProperties'], 'FileExtension':['FileExtension'], 'ViewsLifeTime':['ViewsLifeTime'], 'ParentLink':['ParentLink'], 'FileType':['FileType'], 'IsContainer':['IsContainer'], 'ServerRedirectedURL':['ServerRedirectedURL'], 'ServerRedirectedEmbedURL':['ServerRedirectedEmbedURL'], 'ServerRedirectedPreviewURL':['ServerRedirectedPreviewURL']};
  var cachePreviousItemValuesFunction = ctx['ItemValues'];
  ctx['ItemValues'] = function(slotOrPropName) {
    return Srch.ValueInfo.getCachedCtxItemValue(ctx, slotOrPropName)

        if(!$isNull(ctx.CurrentItem) && !$isNull(ctx.ClientControl)){
            var id = ctx.ClientControl.get_nextUniqueId();
            var itemId = id + Srch.U.Ids.item;
            var hoverId = id + Srch.U.Ids.hover;
            var hoverUrl = "~sitecollection/_catalogs/masterpage/Display Templates/Search/Item_Excel_HoverPanel.js";
            $setResultItem(itemId, ctx.CurrentItem);
            ctx.CurrentItem.csr_Icon = Srch.U.getIconUrlByFileExtension(ctx.CurrentItem);
            ctx.CurrentItem.csr_OpenApp = "excel";
            ctx.CurrentItem.csr_Path = ctx.CurrentItem.Path;
            ctx.currentItem_ShowHoverPanelCallback = Srch.U.getShowHoverPanelCallback(itemId, hoverId, hoverUrl);
            ctx.currentItem_HideHoverPanelCallback = Srch.U.getHideHoverPanelCallback();
,'            <div id="', $htmlEncode(itemId) ,'" name="Item" data-displaytemplate="ExcelItem" class="ms-srch-item" onmouseover="', ctx.currentItem_ShowHoverPanelCallback ,'" onmouseout="', ctx.currentItem_HideHoverPanelCallback ,'">'
,'                ',ctx.RenderBody(ctx),'                '
,'                <div id="', $htmlEncode(hoverId) ,'" class="ms-srch-hover-outerContainer"></div>'
,'            </div>'
,'    '

  ctx['ItemValues'] = cachePreviousItemValuesFunction;
  ctx['DisplayTemplateData'] = cachePreviousTemplateData;
  return ms_outHtml.join('');
function RegisterTemplate_89a1689efe684e93be8c5bdaa1e46b07() {

if ("undefined" != typeof (Srch) &&"undefined" != typeof (Srch.U) &&typeof(Srch.U.registerRenderTemplateByName) == "function") {
  Srch.U.registerRenderTemplateByName("Item_Excel_Client", DisplayTemplate_89a1689efe684e93be8c5bdaa1e46b07);

if ("undefined" != typeof (Srch) &&"undefined" != typeof (Srch.U) &&typeof(Srch.U.registerRenderTemplateByName) == "function") {
  Srch.U.registerRenderTemplateByName("~sitecollection\u002f_catalogs\u002fmasterpage\u002fDisplay Templates\u002fSearch\u002fItem_Excel_Client.js", DisplayTemplate_89a1689efe684e93be8c5bdaa1e46b07);

if (typeof(RegisterModuleInit) == "function" && typeof(Srch.U.replaceUrlTokens) == "function") {
  RegisterModuleInit(Srch.U.replaceUrlTokens("~sitecollection\u002f_catalogs\u002fmasterpage\u002fDisplay Templates\u002fSearch\u002fItem_Excel_Client.js"), RegisterTemplate_89a1689efe684e93be8c5bdaa1e46b07);


Then I pushed the Display Template and Result Type automatically to all Site Collections, because I wanted a uniform experience.

Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction:SilentlyContinue

function DropFile([Microsoft.SharePoint.SPWeb]$spweb, [string]$fileName, [byte[]]$fileContents)
    $spfolderUrl = $spweb.Url + "/_catalogs/masterpage/Display Templates/Search";
    $spfolder = $spweb.GetFolder($spfolderUrl);
    $spfile = $spweb.GetFile("$spfolderUrl\$fileName");
    if ($spfile.Exists)

    $spfile = $spfolder.Files.Add($fileName, $fileContents, $true);
    if ($spfile.CheckOutType -ne "None")

    Write-Host " > Display Template Provisioned."
    return $spfile;

function CreateSearchResultType([Microsoft.SharePoint.SPWeb]$spweb, [string]$spfileUrl)
    $ssa = Get-SPEnterpriseSearchServiceApplication
    $owner = Get-SPEnterpriseSearchOwner -Level SPSite -SPWeb $spweb
    $excelRIT = Get-SPEnterpriseSearchResultItemType -Owner $owner -SearchApplication $ssa | Where Name -eq "Microsoft Excel"
    $rules = $excelRIT.Rules
    $dispProps = $excelRIT.DisplayProperties
    $sptemplateUrl = "~sitecollection/$spfileUrl";
    Write-Host $sptemplateUrl;

    Get-SPEnterpriseSearchResultItemType -Owner $owner -SearchApplication $ssa | Where Name -eq "Microsoft Excel (Client)" | Remove-SPEnterpriseSearchResultItemType -Owner:$owner -SearchApplication $ssa -Confirm:$false
    $rit = New-SPEnterpriseSearchResultItemType -Name "Microsoft Excel (Client)" -Owner $owner -SearchApplication $ssa -Rules $rules -DisplayProperties $dispProps -DisplayTemplateUrl $sptemplateUrl
    Write-Host " > Search Result Type Created."
    return $rit;


$cd = gl
$fileNames = @("Item_Excel_Client.js", "Item_Excel_Client.html");

Get-SPWebApplication "http://mywebapp" | Get-SPSite -Limit ALL | ForEach {
    $spsite = $_;
    $spweb = $spsite.RootWeb;

    Write-Host $spsite.Url

    # Upload File(s)
    $fileNames | foreach {
        $fileName = $_;
        $fileContents = [System.IO.File]::ReadAllBytes("$cd\$fileName");
        $spfile = DropFile $spweb $filename $fileContents;

    # Register Search Result Type
    $fileUrl = $spfile.Url.Replace(".html", ".js");
    CreateSearchResultType $spweb $fileUrl;

Better solution

Recently I stumbled upon the “Preferences” link at the bottom of the search result page. This allows each user to control how links in the search results should be opened.

Search preferences


This actually changes the experience for the given user immediately… awesome! I did some digging and it seems to be saved globally to the Search Service Application (Proxy), so all Web Applications and Site Collections making use of the same SSA should give the user a uniform experience.

The question still stands whether this setting can be pushed out programmatically to a specific user or group of users. I was thinking along the lines of the following script, but no luck so far.

$web = Get-SPWeb http://intranet
$ctx = [Microsoft.SharePoint.SPContext]::GetContext($web)
$pref =[Microsoft.Office.Server.Search.Administration.UserPreference]::GetUserPreference($false, $ctx)


SharePoint Foundation 2013 broken search experience

December 10, 2013 - 10:33, by Steven Van de Craen - 87 Comments


I recently examined a SharePoint Foundation 2013 environment where all Search Boxes had gone missing overnight. Also, when browsing to the Search Center I received an error. The ULS logs showed the following error:

System.InvalidProgramException: Common Language Runtime detected an invalid program.

at Microsoft.Office.Server.Search.WebControls.SearchCommon.GetUserAdvancedLanguageSettingsUrl()

at Microsoft.Office.Server.Search.WebControls.ScriptApplicationManager..ctor()

at Microsoft.Office.Server.Search.WebControls.ScriptApplicationManager.GetCurrent(Page page)

at Microsoft.Office.Server.Search.WebControls.SearchBoxScriptWebPart.OnInit(EventArgs e)

at System.Web.UI.Control.InitRecursive(Control namingContainer)

at System.Web.UI.Control.AddedControl(Control control, Int32 index)

at System.Web.UI.WebControls.WebParts.WebPartManager.WebPartManagerControlCollection.AddWebPartHelper(WebPart webPart)

at System.Web.UI.WebControls.WebParts.WebPartManager.WebPartManagerControlCollection.AddWebPart(WebPart webPart)

at Microsoft.SharePoint.WebPartPages.SPWebPartManager.AddWebPartWithRetry(WebPart webPart)

at Microsoft.SharePoint.WebPartPages.SPWebPartManager.CreateWebPartsFromRowSetData(Boolean onlyInitializeClosedWebParts)

at Microsoft.SharePoint.WebPartPages.SPWebPartManager.LoadWebParts()

at Microsoft.SharePoint.WebPartPages.SPWebPartManager.OnPageInitComplete(Object sender, EventArgs e)

at System.EventHandler.Invoke(Object sender, EventArgs e)

at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

KB2837628 and/or KB2850058

It took some investigating but we managed to track down the Windows Updates that seem to cause this issue: and Installing either on a SharePoint Foundation 2013 will break the search infrastructure. Note that these updates CANNOT be uninstalled.


Other users have also reported the exact same issue and cause on the MSDN forums, but no fix is currently available. The impacted environment had a localized (Dutch) version of SharePoint Foundation 2013 running, other cases also mostly talk about localized versions, so it might be that the English SKU is unaffected.

All versions (both English and localized) of SharePoint Foundation 2013 are impacted.



» (Comments section)



Initially I was unable to reproduce this issue as the aforementioned update wouldn’t install (“The expected version of the product was not found on this system”), but ultimately I did find how it probably ended up on impacted systems.

  1. Install SharePoint Foundation 2013
  2. Install SharePoint Server 2013 March Public Update
  3. Install KB2837628 and/or KB2850058

So basically if you run the Server PU (and maybe this applies to CU’s as well) on a Foundation it will update without issues, but then Windows Updates will start rolling out SharePoint Server 2013 updates. If this is an unsupported scenario they should have a blocking mechanism to avoid installing Server PU’s or CU’s onto a Foundation.

Solution: KB2760625

The October 2013 or December 2013 Cumulative Update do NOT fix this issue. For now avoid installing this update altogether. It isn’t supposed to wind up on Foundation installations.

I’m currently working together with Microsoft PSS to get to the bottom of this and -hopefully- a hotfix.

An hotfix has been released and confirmed to fix the issue: KB2760625 ( After installation the Configuration Wizard needs to be run.

This hotfix should be incorporated into the April 2014 Cumulative Update, so once that is available there shouldn’t be a need to install this specific hotfix separately.


Update (12/12/2013)

There’s are reports that KB2850058 has the same impact, so be careful! but this appears to be false. This update is related to Outlook 2007 Junk Email Filter. I can now confirm this (17/12/2013).


I have also logged this as a support case with Microsoft, let’s hope this can clear the mist. I’ll update my findings here and on the above forums.

Update (13/12/2013)

It appears that English installations of SharePoint Foundation 2013 are also impacted.

I’m still working with PSS to get this resolved.

I haven’t been able to reproduce the issue on my dev environment. I tried WS2012 and WS2008R2 but KB2837628 seems unwilling to install (“The expected version of the product was not found on the system.”). If anyone has reproducible steps please let me know.

Update (14/12/2013)

Managed to reproduce the issue. See above for the reproduce steps.

I verified KB2850058 on my installation. It wouldn’t install because I didn’t have Outlook 2007 on it, but it appears to be unrelated since it is an update for the Outlook 2007 Junk Email Filter. Most likely both updates were installed on the environment of the user that reported this. I had my numbers screwed up.

Update (16/12/2013)

I tried the recently released December 2013 Cumulative Update but no luck.

Microsoft PSS is still examining the issue. To be continued.

Update (17/12/2013)

After getting notified that KB2850058 was really also causing this issue, I retraced my steps and I had gotten the KB numbers wrong. So we have both KB2837628 and KB2850058 causing the same issues. Thanks Lee and Matt for informing me on this via the comments below!

Update (23/12/2013)

I don’t expect a solution to be provided in the next few weeks :(

Update (4/02/2014)

I finally have an update to share after weeks of back-and-forth emailing regarding the issue. I’m absolutely not happy with the answer and have expressed my sentiment accordingly. Still, I doubt that will make an impression on anyone. Here’s the update;

The Product Group is acknowledging the problem but declared that they can only fix it over the April 2014 CU as there will be no February 2014 CU.

This means for the affected customer that cannot wait until April need to reinstall SharePoint in order to address  the error in a supported manner. Some other customers tried to replace binaries with older versions, we haven’t yet received the feedback if this worked out for them – we are asked to discourage this kind of experiments anyway.

Update (5/02/2014)

A final word from the escalation engineer was that this is an acknowledged bug, but due to the release cycles of hotfixes and updates this issue cannot be fixed any sooner than the April 2014 Cumulative Update. Since this is well over two months away from now you’d be best in reinstalling your environment and avoid those specific Windows Updates, or live without Search until then.

Update (4/03/2014)

Service Pack 1 for SharePoint Foundation 2013 does not fix this issue. Furthermore, the KB for Service Pack 1 was amended with a notice to postpone installing SharePoint Foundation 2013 Service Pack 1.

Important A known issue in SharePoint Foundation 2013 SP1 can affect the functionality of the Search WebPart. We encourage you to limit production installations of SharePoint Foundation 2013 SP1 until a fix is available. SharePoint Server 2013 is not affected by this issue.

Update (20/03/2014)

A hotfix has finally been released:! Make sure to run the Configuration Wizard afterwards.

Get the Search Service Application for a specific site (programmatically)

October 30, 2013 - 13:46, by Steven Van de Craen - 0 Comments

I needed to get a reference to the Microsoft.Office.Server.Search.Administration.SearchServiceApplication instance for a given Microsoft.SharePoint.SPSite instance.

Here’s how you can do this in C#. I created it as an Extension Method.

public static SearchServiceApplication GetSearchServiceApplication(this SPSite site)
    SearchServiceApplication result = null;

    if (site != null)
        SearchServiceApplicationProxy proxy = (SearchServiceApplicationProxy)SearchServiceApplicationProxy.GetProxy(SPServiceContext.GetContext(site));

        if (proxy != null)
            Guid ssaId = proxy.GetSearchServiceApplicationInfo().SearchServiceApplicationId;
            result = SearchService.Service.SearchApplications[ssaId] as SearchServiceApplication;

    return result;

And here’s the PowerShell counterpart. I’m no scripting guru so this might be improved here and there.

function GetSearchServiceApplication([Microsoft.SharePoint.SPSite] $site)
    if ($site -ne $null)
        $proxy = [Microsoft.Office.Server.Search.Administration.SearchServiceApplicationProxy]::GetProxy([Microsoft.SharePoint.SPServiceContext]::GetContext($site));

        if ($proxy -ne $null)
            [System.Guid] $ssaId = $proxy.GetSearchServiceApplicationInfo().SearchServiceApplicationId;
            $result = [Microsoft.Office.Server.Search.Administration.SearchService]::Service.SearchApplications | ? { $_.Id -eq $ssaId };

    return $result;

May it serve you well!

SharePoint Server 2010 and PDF Indexing

January 5, 2012 - 11:22, by Steven Van de Craen - 0 Comments

Posting this for personal reference:

SharePoint 2010 - Configuring Adobe PDF iFilter 9 for 64-bit platforms

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\14.0\Search\Setup\ContentIndexCommon\Filters\Extension\.pdf]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\14.0\Search\Setup\Filters\.pdf]

reg-file sps2010pdf.reg

SharePoint Search Scopes: Approximate Item Count is incorrect

March 18, 2010 - 15:28, by Steven Van de Craen - 1 Comments

The Scope Item Count gives an approximate number of items matching the scope. However at one of my customers it showed only six items for their entire file share !?


There were no Crawl Rules and the Crawl Logs showed tens of thousands of successfully crawled items so what could be wrong ? I played with the scope rules (recreated them, inverse logic, etc) but no luck. I opened up Reflector on the Scope Count property to find that it is calculated through a Search Query. Then it hit me that the account I logged in to to perform Search Administration was a local account that didn’t have access to the file share, thus the Query for returning Scope Count would security trim those results for me.

I’d expect any SharePoint Administrator to get a correct count of items in the Scope so this seems like a minor design flaw to me.

 Next >>