Monthly Archives: June 2014

SharePoint Search & Migration Part 4: Search Result Types and Display Templates

In a few series of posts I will discuss changes in SharePoint Search which might affect you when migrating from SharePoint 2010 to 2013. Search is one of the most changed components in SharePoint 2013 and therefore I split the posts up in four parts covering some subjects you need to know before migrating to SharePoint 2013. All parts will be available with the links below when the posts are available:

Part 1: Search Settings
Part 2: Search Web Parts
Part 3: Search Results Sources
Part 4: Search Result Types and Display Templates

In this post I’ll discuss Search Result Types and Display Templates. Both are new features coming with the new Search platform in SharePoint 2013. You’ll need them in case you want to customize the way how search results are displayed. In the past XSLT was the way to go by changing the search results page and change the Web Part settings XSLT. In 2013 this functionality is no longer available and Results Types and Display Templates are the way to go.

Let’s focus first on Result Types. Microsoft provides on MSDN a nice article which gives you a basic understanding of what it is. In short: when searching you’ll get results back of different types. A site is different from a library, a word document is different from an excel document or image, etc. Each type of result is defined as a Result Type. Out of the box a set of result types is predefined like all types of Office documents, pages, sites, libraries, etc. Per type a Display Template is coupled which determines how the result of the specific type should be rendered in the Search Results Web Part. Result types are managed per Site Collection and Web. In the Site Settings menu you can select Search Result Types for managing them on Site Collection level and Result Types to manage them on Web level. After opening the page you’ll see a screen with all result types on the site collection or web:

Manage Result Types

Manage Result Types page for Site Collection Administrator

All out of the box delivered Result Types are read-only. This is similar as with Result Sources, where the out of the box settings are also read-only. When we open one of the Result Types we can see how it’s configured and what you can configure:

View Result Type page

View Result Type page

For each Result Type you can specify the name and conditions. The conditions filter first on Result Sources. You can also select the option to use all if you don’t want to filter on it. Next you can filter on the type of results. This is a predefined set of types which SharePoint recognizes. When you expand “Show more conditions” you have the ability to create filters based on Managed Property values. In case you have added additional fields to specific content types and you want to filter on them you can use this functionality to add a filter. The last option you need to select a Display Template. This list is created based on the approved Display Templates in the Master Page Gallery (in the subfolder Display Templates). This is actually the template that is used to render the Search Result which is matching this Result Type. When created it will appear in the top section of available Result Types.

Now we have discussed the Result Types we can focus on Display Templates. Display Templates are the replacement for XSLT and provide a powerful way to create templates within SharePoint. Microsoft has again a good article about what a Display Template is. Display Templates are stored inside the Master Page Gallery in a subfolder called Display Templates. Inside that folder there a some subfolders for specific categories of Display Templates. In our case we need to open the Search folder and that should look like the screenshot below:

Search Display Templates

List of Search Display Templates in the Master Page Gallery.

In case the Publishing Infrastructure feature is not activated on the Site Collection, you’ll only see .js files. Be aware of this! In that case if you don’t want to activate it and want to create or change display templates, read this article  from Martin Dreyer where he describes how to change display templates on non-publishing websites. On publishing websites you should ignore the .js files. They are automatically updated by SharePoint when you make changes to the HTML files. The MSDN article which I’ve shared already describes how you can change Display Templates. You can adjust them to display for example additional Managed Properties or change the styling. On the internet you can find a bunch of examples to built-in pretty cool stuff with display templates. A small selection is stated below:

Add twitter links using Display Templates
Image Slider
Customize Display Templates and deploy them using a solution

Setting up SharePoint 2013 devbox for provider hosted apps

For preparing another article I was trying on my pretty straight forward dev box to debug an empty provider hosted app solution. However I was experiencing some problems with setting up my dev box to allow provider hosted apps to run on the same box using IIS Express. First I started with a blank new SharePoint 2013 App solution in Visual Studio 2012 and tried to deploy it on my machine (using a IISExpress instance for running the actual contents of the app). First deployment was failing because the services needed to run apps where not running. Make sure that the appropiate services are running as shown in the following screenshots:

AppManagementService

The App Management Service Application should be started.

AppManagementService2

The App Management Service should also be started.

After starting the services and performing an IISReset I could successfully deploy the app to SharePoint. A window will open with the question to trust the app. After that I was getting the following exception:

TokenError

A token error which was occurring…

After googling a bit around on this error I found an >article which explains why it isn’t working. The app is trying to authenticate using the so-called Low-Trust model and expects Access Control Service (ACS) as a trust broker. I decided that I want to use High-Trust because I don’t want to rely on an internet connection in the dev box to connect to O365 ACS. The advantage is that you don’t need Office 365 for ACS, the disadvantage is the bunch of configuration work to do. First you need to do some preparation work which is described by Microsoft in the following article. Probably you already have a farm installed, so you can start at step 6. To make it easier I included the full PowerShell script from the article here with some useful comments:

#Start SharePoint Services
net start spadminv4
net start sptimerv4

#Set App Domain, change name if you want to
Set-SPAppDomain "App-Domain"

#Verify services are started
Get-SPServiceInstance | where{$_.GetType().Name -eq "AppManagementServiceInstance" -or $_.GetType().Name -eq "SPSubscriptionSettingsServiceInstance"} | Start-SPServiceInstance
Get-SPServiceInstance | where{$_.GetType().Name -eq "AppManagementServiceInstance" -or $_.GetType().Name -eq "SPSubscriptionSettingsServiceInstance"}

#Create new managed account, remove this line if you already have one!
$account = New-SPManagedAccount

#Create services for app domain, please change domainname\username to correct user
$account = Get-SPManagedAccount "domain\user" 
$appPoolSubSvc = New-SPServiceApplicationPool -Name SettingsServiceAppPool -Account $account
$appPoolAppSvc = New-SPServiceApplicationPool -Name AppServiceAppPool -Account $account
$appSubSvc = New-SPSubscriptionSettingsServiceApplication –ApplicationPool $appPoolSubSvc –Name SettingsServiceApp –DatabaseName SettingsServiceDB 
$proxySubSvc = New-SPSubscriptionSettingsServiceApplicationProxy –ServiceApplication $appSubSvc
$appAppSvc = New-SPAppManagementServiceApplication -ApplicationPool $appPoolAppSvc -Name AppServiceApp -DatabaseName AppServiceDB
$proxyAppSvc = New-SPAppManagementServiceApplicationProxy -ServiceApplication $appAppSvc

#Change tenant name if you want to
Set-SPAppSiteSubscriptionName -Name "app" -Confirm:$false

After executing the script you’ll see new service applications popping up in Central Administration:

NewServiceApplicationsAppManagement

New service applications and proxys has been added by the script.

Then you can start with the preparations to create your High-Trust Provider Hosted app. Microsoft described this again in a article. Again I’m sharing the PowerShell which is posted along the article:

#Path to exported certificate, change if needed
$publicCertPath = "C:\Certs\HighTrustSampleCert.cer"

#Read certificate and create trustrootauthority
$certificate = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($publicCertPath)
New-SPTrustedRootAuthority -Name "HighTrustSampleCert" -Certificate $certificate

#Create Trusted Security Token Issuer 
$realm = Get-SPAuthenticationRealm
$specificIssuerId = "11111111-1111-1111-1111-111111111111"
$fullIssuerIdentifier = $specificIssuerId + '@' + $realm
New-SPTrustedSecurityTokenIssuer -Name "High Trust Sample Cert" -Certificate $certificate -RegisteredIssuerName $fullIssuerIdentifier –IsTrustBroker
iisreset 

#Configure to use without HTTPS, don't use this on NON-DEV boxes!!!
$serviceConfig = Get-SPSecurityTokenServiceConfig
$serviceConfig.AllowOAuthOverHttp = $true
$serviceConfig.Update()

The article also describes what to do when creating the solution in Visual Studio. You need a .pfx export of your certificate with private key to let it work. When running the default sample you should see at the end a page with the Site Title displayed on it:
App

Now you can start creating your app! Happy coding!

SharePoint 2013 Lazy loading Javascript

In SharePoint 2013 the Javascript loading mechanism seems to be changed a bit. When porting a SharePoint 2010 solution to 2013 I found out that sometimes some weird script errors where occuring when calling SharePoint Javascript libraries. On some pages in SharePoint 2013 it happens that not all SharePoint Javascript libraries are loaded because of the built-in lazy loading mechanism. This reduces bandwidth when loading pages, because no unneeded libraries are downloaded to the client. But this causes issues when you want to use not loaded libraries. The following sample Javascript codes shows how you can load some Javascript Libraries and then automatically call your function where you want to use those libraries:

//Register SOD's
SP.SOD.registerSod('core.js', '\u002f_layouts\u002fcore.js');
SP.SOD.executeFunc('core.js', false, function(){});;
SP.SOD.registerSod('sp.js', '\u002f_layouts\u002fsp.js');
SP.SOD.executeFunc('sp.js', false, function(){});
SP.SOD.registerSod('sp.core.js', '\u002f_layouts\u002fsp.core.js');
SP.SOD.executeFunc('sp.core.js', false, function(){});

function doSomething() {
   //Your Logic here which calls sp core libraries
}

// Load asynchronous all needed libraries
ExecuteOrDelayUntilScriptLoaded(function() { ExecuteOrDelayUntilScriptLoaded(doSomething, 'sp.core.js') }, 'sp.js');

In the example above we’re using the SP.SOD library provided with SharePoint. Those existed already in SharePoint 2010 and are still present in 2013. With the SOD library it is possible to lazy load Javascript files and load them on the moment you need them. The sample script exists of three parts. In the first step we register Sod’s (Script on Demand) where we define a key and as value the relative path to the Javascript file. We also call executeFunc to load the file using a dummy function. In the second step we create a custom function. This is the function where you want to call specific methods in the Javascript libraries loaded. Then we call ExecuteOrDelayUntilScriptLoaded. Because in this sample we want both sp.core.js and sp.js loaded, we nest it with another call to ExecuteOrDelayUntilScriptLoaded and finally let the callback call the function which needs the libraries loaded before executing. This method of loading scripts seems to work well in SharePoint 2013 and can also be used for other OOTB Libraries, like the Taxonomy Javascript Library. When your site is still running in SharePoint 2010 mode however, this doesn’t work properly. The registering of Sod’s seems to break with the 2010 way of loading the OOTB Javascript files so there you need only the ExecuteOrDelayUntilScriptLoaded calls. If you need to detect the mode in Javascript you can use the SP.Site.get_compatibilityLevel() function to retrieve that info using JSOM and then dynamically decide which method of loading to use.

SharePoint Migration & Search Part 3: Result Sources

In a few series of posts I will discuss changes in SharePoint Search which might affect you when migrating from SharePoint 2010 to 2013. Search is one of the most changed components in SharePoint 2013 and therefore I split the posts up in four parts covering some subjects you need to know before migrating to SharePoint 2013. All parts will be available with the links below when the posts are available:

Part 1: Search Settings
Part 2: Search Web Parts
Part 3: Search Results Sources
Part 4: Search Result Types and Display Templates

In this post I will cover the new Result Sources functionality in SharePoint 2013 and the impact on SharePoint migrations from SharePoint 2010. When upgraded to SharePoint 2013 your Site Collections will remain in 2010 mode in the beginning. In that mode all functionality which was present in 2010 will keep working including Search Scopes. When upgrading your Site Collection to 2013 mode a few things the Search Scopes will become read only. Editing and deleting is blocked in UI and in the API. When trying to modify Search Scopes from API you will get an exception. When creating Search Scopes using custom code, you need to check in which mode your site collection is running. You can easily implement that by checking the CompatibilityLevel property of the SPSite object:

using(SPSite site = new SPSite(siteUrl)
{
    if(site.CompatibilityLevel == 14)
    { // Add your 2010 mode code here

    }
    else if(site.CompatibilityLevel == 15)
    { // Add your 2013 mode code here

    }
}

As I explained in Part 2 of these Search series, also the Search Web Parts are changed so that implicates that you need to mitigate Search Scopes. Result Sources are the replacement for this in SharePoint 2013. The Search Scopes can be managed on three levels: Farm, Site Collection and Web. Out of the box SharePoint will provide 16 Result Sources. You can’t edit or delete the default Result Sources, but you can create new ones based on the default ones. Creating can be done on all three levels where Search Settings can be managed, but they will be available only within that scope. When adding a new Result Source a form will open where you can select the source where should be searched in and there is the ability to create custom query transformations using a Query Builder.

QueryBuilder

With the Query Builder it is possible to create custom query transformations using the User Interface.

Within the custom Query’s you can include managed properties which makes it very useful to create Result Scopes for using custom fields and content types. When added a Result Source, you can use it in customized search pages and make it available to end users by adding it in the Search Navigation. There’s a Technet Blogpost which describes this process.