Thursday 27 August 2015

SharePoint 2013 Custom Search - Part 3 - Display Templates

This is the final part in a three-parter on leveraging SharePoint 2013 custom search and a business solution, this follows directly on from SharePoint 2013 Custom Search - Part 2 - Result Sources and Query and will focus on the display of results.

SharePoint 2013 makes heavy use of display templates throughout the platform. Microsoft have now made it easier than using XSLT (which is a relief!) to display search results and in a similar way to the way the masterpages are controlled, you simply upload a html/javascript version of your display template and SharePoint - via the use of jiggery-pokery and magic - creates the necessary .js file! Awesome!

Ok, so lets get to it! We saw before we 

The amount of data that was returned by a data connection has exceeded the maximum limit that was configured by the server administrator SharePoint infopath 2010 error

So we have a lot of InfoPath forms in my current company and an error that appeared recently was this:

The amount of data that was returned by a data connection has exceeded the maximum limit that was configured by the server administrator.

Click OK to resume filling out the form. You may want to check your form data for errors. 







Reason:The warning message usually comes if the Default data connection response size increases. By default, The Default data connection response size is set to 1500kb for InfoPath Form Services. In my case, the data connection response size was already 8000kb, so I needed to increase it further.
Resolution:Open SharePoint 2010 Central Administration. 
Go to General Application Setting and then click on Configure InfoPath Forms Services from InfoPath forms Services section as shown in the figure below:



Then change the Data Connection Response Size to something higher, in my case I changed to 21200kb.



Then press ok.

Refresh your site and reopen the InfoPath form, this time without this warning message.


Thursday 7 May 2015

SharePoint 2013 Custom Search - Part 2 - Result Sources and Query

This post follows directly on from my other post SharePoint 2013 Custom Search - Part 1 - Managed Properties which guides you through making your searched (crawled) data available to use in your solutions.
This post builds on this and uses this data in a meaningful way, pulling this into Search results by way of display templates - a new feature for displaying content in SharePoint 2013..

My end goal is to produce a search driven page that returns refine-able information about the way an IT project went, this information is captured in a retrospective meeting after the project has completed, the information captured is based around the 'feeling' e.g. positive, negative or warning.

The user experience i'm after is for a user to be able to search for a key word (or an asterisk * to search all content) and the same page display results showing custom information, with the ability to hover over these to provide further information.

The data for this is coming from a list, with columns that have been created, mapped and crawled following the principles outlined in my first post in this three-parter.






A list including crawled data, the next new thing to 2013 Search is the concept of a 'Result Source' this replaces the old 'scopes' from 2010. Head to Settings-Site Settings-Result Sources



You will see a list of Result Sources provided by SharePoint, take a look at these to familiarise yourself with the way they are created and the various ways these can be implemented.

To create a new result source, click (yes you guessed it) 'New Result Source'.
The purpose of this result source is to return results that only exist in a specific location - in this case the list above. So the settings we want here are:
Name: RestrospectiveLearning
Protocol: Local SharePoint
Type: SharePoint Search Results

Now for the query, hit 'Launch Query Builder'. Here we're stringing together three query parameters to get the right results.




?{searchTerms} - Is the internal variable for whats typed in the search box
Path:http://xxxx - Is the URL path of the results we're after
(contentclass:STS_ListItem) - Is the type of data we're looking to retrieve


Testing your query will return no results as there is no search term, so this is correct.

The next thing to do is create a page on which to add a search box and search results webpart, this will be the home for our users for this particular solution, they shouldn't need to navigate away from this page.



Here we have a plain old web part page and as you can see I've added a Search Box web part, Search Results web part and a Refinement web part (ok I've missed one, you can see a Script Editor web part here, I tell you what this does later, I promise!)

We need to link the Search Box and the Search Results web parts together so the results go to the right place! Simply edit the Search Box properties and tick the box that send results to the Search Results web part.



Now to configure the Search Results web part, so again edit the web part and choose 'Change query'




Next we see the query builder that SharePoint 2013 uses all over the place, this is similar to the one we used creating the result source.



This time we simply select the result source we created earlier. 

As for the refinement panel, edit the webpart and provided you have set the managed property (part 1 of this series) to 'Refinable' it will be available to select here, add the ones you wish to refine your results to 'Selected refiners'



Now for the elusive Reset Button you saw earlier. The reason this is included is I want results to appear for the users when they load the page. To achieve this, I need a wildcard (*) as a search term. I've added a script editor webpart and included the following javascript, firstly this changes the URL on page load to include the query '*' and secondly do the same thing when a button is pressed (labelled 'Reset').

<script type="text/javascript">
window.location =  '/sites/Retrospective-Learnings.aspx#k=*'
</script>
<div>
<input type="button" name="ResetBttn" title="Click to reset" style="margin-left: 0px;" onclick="location.href = '/sites/Retrospective-Learnings.aspx#k=*'" value="Reset">
</div>

Now to test.
Typing a term in the search box will now display desired results from the correct list in the search results web part. However, these are not styled as we would like as you can see..










Checkout SharePoint 2013 Custom Search - Part 3 - Display Templates for how to style this and bring it all together.

Wednesday 6 May 2015

SharePoint 2013 Custom Search - Part 1 - Managed Properties

This is the first in a three part blog which will focus on leveraging SharePoint 2013 Custom Search in a real world business solution, part one is creating managed properties, part two looks at getting these as part of result sources and querying, and finally part three brings it together with a bit of custom styling using display templates.

OK, so Microsoft have changed the way they have implemented Search in SharePoint 2013 - in quite a massive way if you didn't already know. 


Alongside some of the larger changes, there are a few smaller ones which aren't immediately obvious.

Once upon a time to configure managed properties, one had to venture into the 'Metadata Properties' section in 2010:



The game has changed a little, and this option is now embedded in 'Search Schema' in the 2013 world:


If you've already added managed properties in 2010 I hate to tell you how to suck eggs, but I'll cover it anyway as there are a few more changes, I'll point these out as we go on...

A few ground rules on managed properties and crawling -
Rule 1: You have to map a managed property to a crawled property

Rule 2: A crawled property is not a crawled property until its been crawled (kind of makes sense, but the next rule will clarify)

Rule 3: A crawled property is not registered as crawled unless there is some data against it

Rule 4: You have to run a full crawl before data in a crawl property is crawled

Hopefully that all makes sense, but basically, to add a managed property; create the column in SharePoint, add an item with data against that column, run a full crawl and the crawled property will be visible in central admin.

There will be a few of you reading this know your stuff that will be like 'hang on a minute, why do I need to map a crawled property to managed one in SharePoint 2013?'

Well the answer is - you dont! SharePoint 2013 has added a neat feature which creates a managed property automatically on a full crawl for any columns that contain data. However, I prefer to create mine manually for a few reasons.
Take the following two managed properties:


They both actually crawl the same value and will return the same thing, however the automatically created one (at the top of the screenshot above) you will see has a somewhat messy name appended with OWSTEXT. In addition, if you wanted this property to be searchable (which is extremely likely) you would have to edit the property as its created with only query and retrieve attributes.

So to create a managed property (after the rules above have been followed) choose 'Add New Managed Property' in the resulting screen give it a meaningful name (I would create this without spaces to make this easier to reference in javascript / html / xsl later):



Select the attributes that you wish this property to have:

Map this to a crawled property (you can map this to more than one crawled property!):



You are now able reference the values from crawled properties in your solutions using the managed property name. To read about how to achieve this as part of a business solution take a look at the second part in this series:




Tuesday 5 May 2015

New SharePoint 2013 Server Service - Distributed Cache

We recently installed our SharePoint 2013 server farm (and by recently, I mean around a year ago). I noticed a new server service that could be run in our farm called "Distributed Cache".


What is Distributed Cache?

Well, basically what it says on the tin, a caching functionality in SharePoint 2013. It is either required by or improves the folllowing features in SharePoint 2013:


  • Authenication
  • My Site Newsfeeds
  • Access for OneNote client
  • Security
  • Page loading performance
This service was not available in SharePoint 2010 like it is now in SharePoint 2013.

So when planning for this, you may want to consider using a dedicated Distributed Cache server or allocated memory to the Distributed Cache. The latter would affect performance however.

I have started the Distributed Cache server on our 2 Web Front End servers which are load balanced.

Planning for feeds and the Distributed Cache service can be found here:


Managing the service can be found here:


And a full overview of Distributed Cahce is here:

Unable to Modify View: /_vti_bin/owssvr.dll?CS=65001

So I received an email from one of my key stakeholder's a few days ago saying they were unable to modify a view as everytime they pressed OK on the Modify View page, there received a funny looking error:


ERROR:

The error below shows: _vti_bin/owssvr.dll?CS=65001 after the normal URL. Therefore something along the lines of: http://SharePointTest/_vti_bin/owssvr.dll?CS=65001



After searching through the logs and finding various Trace logs in my ULS viewer, there wasn't quite much there to resolve my issue.

Something to note here is however, that I do have Server Publishing Feature activated.

RESOLUTION:

I searched a bunch of articles online and eventually found one mentioning about something called "Minimal Download Strategy" or MDS feature. On my site features, I happened to have this activated. I believe that is doesn't really work with items such as the Publishing Portal, Enterprise WIKI and Project Web App.



I de-activated this feature and suddenly, I was able to modify views and no error appears anymore.

This is a new feature in SharePoint 2013 and is automatically activated on Team Sites. This feature reloads parts of a page that have changed. When modifying the view, the whole page has changed and for some reason, throws up this error.



Monday 21 July 2014

Configuring Apps for SharePoint 2013

Let’s take a look at making use of the one of the new features of SP2013, Apps. Whether you’re planning to use downloadable apps across your organisation or a developer creating your own, both require a correctly configured app infrastructure.
MS recommend that you have a separate domain name for Apps that is not a child of the domain in which your servers are sitting. They also say you need to ‘purchase’ a domain name, what they fail to say is this is only applicable if your publishing apps externally. If, like me you’re configuring this within the walls of your corporate network, then simply creating a new domain is possible without making a purchase in the real world.
Important! – This isn’t creating a new domain as you may imagine, because that does sound overkill right? Actually it’s about creating a domain (zone) in DNS. This then needs to have a wildcard alias. This is so your App namespace can eventually be ‘AppName.DomainName’.

Head over to your DNS console and create a new Forward Lookup Zone, this should be of type ‘Primary’ and replicate to all DNS servers in the domain.


Now this is present, we now need a new Wildcard Alias for this zone. Right click on the new domain you just created and choose CNAME, add an * to denote wildcard in the Alias Name section. In FQDN, add in the full URL of your SharePoint site.


OK, were done now for DNS, let move onto to configure SharePoint. We need two service applications created to deal with the App infrastructure, App Management Service Application and Subscription Settings Service Application, and their associated proxies.

As for App management, not really anything out of the ordinary here. Central Admin – Service Applications – New – App Management Service

Give the Service Application a decent name, its own database and app pool and let it create an App Management Service Application Proxy.



When done this will appear in the list of Service Applications


Now for the harder bit, the Subscription Settings Service Application cannot be created in Central Admin. PowerShell only for this one folks.

Open up the SP Management Shell on of your 2013 servers, run the following to set a variable with the desired managed account, obviously his account must be present in managed accounts in central admin – security:

$account = Get-SPManagedAccount "ServiceAccountName" 

OK, now let’s create a new application pool using the account we set earlier and store to a variable.
 
$appPoolSubSvc = New-SPServiceApplicationPool -Name “Subscription Settings Service Application Pool” -Account $account



And now to bring it all together, creating the service application using the variable we created before, we’re adding the name of the Service Application here and giving it a database name:

$appSubSvc = New-SPSubscriptionSettingsServiceApplication -ApplicationPool $appPoolSubSvc -Name “Subscription Settings Service Application” -DatabaseName SharePointSubscriptionSettingsService



And finally, the proxy for the Settings Service Application, we don’t get the option of giving it a name here.

$proxySubSvc = New-SPSubscriptionSettingsServiceApplicationProxy -ServiceApplication $appSubSvc



Worthwhile heading to Central Admin – Security – Service Accounts and checking that your new Pool is present with the correct managed account attached.

Also we should have our new Service Application and proxy in the Service Application list

Now, head over to Application Management – Manage Services on Server and make sure the ‘App Management Service’ and (this one is harder to spot) the ‘Microsoft SharePoint Foundation Subscription Settings Service’ has been started.



Now give the box a cursory IISRESET


Head to Central Admin - Apps and click on Configure App URL’s

A tell tale sign here that you’ve configured everything correctly! If there is an error, you haven’t!
On this screen we set supply SharePoint with the app domain we created earlier in DNS. Also you need to go for a prefix for the apps. I’ve gone for SP, but you can go for anything you want.


Time to create an App Catalog Site. Choose ‘Manage App Catalog’ from the Apps page in Central Admin.
Change the web application to the one in which you wish to create the site collection, and select ‘Create a new app catalog site’


Hit next and at the next screen you create a site collection just like any other. The only difference being adding the ‘End Users’ i.e. group of people that can see the apps in the store.
You can add AD groups in here or individuals. If this is for all your users, then add ‘Everyone’, that should cover it.

Okay, so now we run into a bit of a gotcha. Although everything is configured correctly, and you can head to the app catalog and add apps. If you attempt to use an app you've added you will get a HTTP 404. This is due to our wildcard domain we created in DNS. The app URL will be correctly produced, with the prefix-appid.domain which in-turn resolves to your SharePoint box but obviously IIS is not recognising this host header and knowing which web application to route it to.

The solution to this is to create an 'empty' web application on port 80 without a host header. This will then receive any unrecognised requests and know what to do with them. Give this a name of something descriptive, I've called mine 'SharePoint App Host', on port 80 and leave the host header blank.

Important!
- Make sure the app pool you choose has access to the web application databases you're using for your apps. Otherwise you will get random access issues. So you want to choose the same app pool as your other web applications, or, if creating a new one (as I am in the screenshot below) choose the same security account you used for the other pool..



You'll notice in the screenshot above that I've called the database 'temp' this doesn't matter as when the web application has been created, you can go to Databases - Manage Content Databases and remove this.

Now you should be able to add, use and develop apps!