Sunday, May 25, 2014

Introduction to SharePoint 2013 search Display Templates

When we consider SharePoint 2013 features, Search is given a high priority. Some SharePoint sites are entirely driven by search where they have search web parts to discover relevant information.
In many cases the default look and feel of search web parts are not adequate. We may need to add more information or simply change the user experience of those web parts. In SharePoint 2010 we had to change the XSLT of the web part to do those modifications. But with SharePoint 2013 that is no longer an option.
We need to modify or create templates (HTML) those render information for search web part. Those templates are called Display Templates.
Rather than explaining Display Templates in a single post, I’ll discuss each topic in different blog posts as below
It’s essential to know important components of a search web part prior to the discussion on Display Templates. Then we will learn how those components map in to Display Templates.
As I mentioned in the above diagram, a search web part can have three main components. They are,
1. Control search results
This manages overall structure of the web part. If we need to change how a collection of result is displayed (e.g.: as lists, images, slides , etc..) we need to change the control search results component. To do the change we have to modify relevant “Control Display Template”.
2. Search result item
This represents an individual search result item within a search web part. To change the design of search result items we have to modify relevant “Item Display Template”.
An Item Display Template calls Item_CommonItem_Body template to render it’s body.
3. Hover Panel
This represent the popup which contains additional information on a search result item. To change the look and feel of this component we have to change relevant HoverPanel Item Display Template.
A HoverPanel Item Display Template calls Item_CommonHoverPanel_Body template to render it’s body
As mentioned in the below image, each type of Display Template does not operate in isolation. They have a relationship with each other.
You can find those templates in “<Site URL>_catalogs/masterpage/Display Templates/Search”. It’s better to map above URL as a network drive to easily access those files.
As you can see there are two files for each Display Template. We have to create the html file where the SharePoint itself will generate the respective JavaScript file. Generated JavaScript file is used as the Display Template internally.
Hope this post gave you some background knowledge on search Display Templates.
We will discuss further on Item Display Templates in our next blog post

Thursday, May 15, 2014

Get all files with their metadata under a particular folder using _api/web SharePoint service

When we create SharePoint 2013 workflows or apps we may need to use SharePoint web services to access data. Let’s assume that we need to get a list of files and their metadata under a specific folder in SharePoint document library.

We can use methods provided by “_api/web/” to access such information. In this post I'll explain about two methods I use to access files and their metadata. A full list of “_api/web/” on this regard can be found on this article.

1. GetFolderByServerRelativeUrl method to get list of files under a folder
In this sample scenario I have few files in a folder named Folder1 which is created in a SharePoint document library.
I’ll use following service to get information about each file under that folder
http://sp13:8080/sites/1234/_api/web/GetFolderByServerRelativeUrl('Shared Documents/Folder1')/Files
As a result I got following information (extract for one entry only)
2. GetFileByServerRelativeUrl to get more information on a particular file
GetFolderByServerRelativeUrl()/Files provides us with limited set of information on a particular file (e.g.: ContentTypeId is missing). If we need further information we can use “GetFileByServerRelativeUrl“ method

To get more information about File1.txt we can use the following service
http://sp13:8080/sites/1234/_api/Web/GetFileByServerRelativeUrl('/sites/1234/Shared Documents/Folder1/File1.txt')/ListItemAllFields 
As a result I got following information 

Monday, May 12, 2014

Could not establish trust relationship for the SSL/TLS secure channel–multi server environment with self-signed certificate for SharePoint 2013 workflow manager

Let’s assume that we have a multi server SharePoint 2013 farm and we need to setup workflow manager in one of them. Following is a sample scenario


If we need the workflow management site over HTTPS we need to configure a SSL certificate. The easiest option would be to configure a self-signed certificate. But it may not work as the certificate is issued by the same server (app server) which is not registered as a valid certificate authority.


When the workflow management site is accessed internally by the WFE Server it throws following error as the certificate is not trusted.

System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.
   at System.Net.TlsStream.EndWrite(IAsyncResult asyncResult)
   at System.Net.ConnectStream.WriteHeadersCallback(IAsyncResult ar)
   --- End of inner exception stack trace ---
   at Microsoft.Workflow.Common.AsyncResult.End

So how can we resolve the error?

The solution is to use a domain certificate instead of self-signed certificate. To do that we need to ensure “Active Directory Certificate Services” role is deployed in one server within the domain.

If “Active Directory Certificate Services” is available we can use following steps to request a domain certificate

1. In App Server go to Microsoft Management Console and add snap-in for Certificates


2. Select computer account



3. Navigate to Personal > Certificates


4. Click Request new certificate


5. Use this certificate for workflow manager configuration

Thursday, May 8, 2014

Access is denied due to invalid credentials – When accessing SharePoint 2013 workflow manager via host named URL

When we configure workflow manager for a SharePoint 2013 farm with publically accessible sites, following can be requirements for the workflow management site

  • Availability via HTTPS
  • Host named URL to match the trusted certificate

After configuring above features, the workflow management site was inaccessible via the host named URL. Although the credentials I provided were accurate, it wasn’t allowing me to access the site.


This error is caused by the loopback check security feature of Windows. If you need to check more on loopback check and workarounds you can refer to this KB article.

Following are summarized  steps to resolve the error.

1. Navigate to following windows registry key


2. Create a new Multi-String value named BackConnectionHostNames


3. Modify the Multi-String value and add the host name


That’s all we need to do. Now the workflow management site is available via the host named URL as below


Sunday, May 4, 2014

Resolve <nativehr>0x80070005</nativehr> at Microsoft.SharePoint.SPGlobal.HandleUnauthorizedAccessException(UnauthorizedAccessException ex) at Microsoft.SharePoint.Library.SPRequest.CreateSite in SharePoint 2013

Above exception was occurring frequently when SharePoint sites are created from an external system.

In our SharePoint environment we have a WCF service to create sites based on a customized site template. In the site creation method we have following code block wrapped with RunWithElevatedPrivileges to create site collections in a particular web application.

  1. var webApp = SPWebApplication.Lookup(new Uri(appUrl));
  2. var site = webApp.Sites.Add(siteUrl, siteTitle, "", 1033, "ContosoSites#01", login, userName, "");

We found that the application pool account of the site creation WCF service does not have sufficient permissions. Following are the steps we followed to resolve the error

1. Change the application pool account of the WCF service

Use application pool credentials used for central administration (SharePoint\SP_Connect) as the application pool identity of the WCF service


2. Add permissions to the web application

Navigate to user policy for the web application and provide full control to the application pool account


That’s all we need to do.