Tag Archives: SharePoint

Open SharePoint 2013 Search Results In The Client Application

If you configure SharePoint 2013 to work with Office Web Apps (link), by default SharePoint will open Word, Excel etc. documents in the browser using the Office Web Apps.  You can configure SharePoint to open documents in the client application or browser on a site collection or document library basis, see here.  However, even if you choose to configure SharePoint to open documents in the client application at the site collection, search results still open in the browser.  In my case I wanted Office Web App integration to enable search result previews, but I wanted search results to open in the client application.

In order to open search results in the client application I had to alter the Item_CommonItem_Body.html search results display template.  Item_CommonItem_Body.html is the display template that’s rendered  by _#=ctx.RenderBody(ctx)=#_ within a display template.  Below is the section in one of my custom display templates.

Search2013WebApps1For an overview of display templates read this MS Technet blog article.

Within Item_CommonItem_Body.html is a section that references ctx.ScriptApplicationManager.states.openDocumentsInClient.

Search2013WebApps2

In order to force search results to open in the client application I added a line in my custom display template to set the value of ctx.ScriptApplicationManager.states.openDocumentsInClient to true.

Search2013WebApps3

Open in Client Detail

This results in the behavior where search result previews using Office Web Apps still work, but when a user clicks on a result it opens in the client application.

 

Enabling SharePoint Search With An Active Directory Forest Trust

Having configured SharePoint 2010 Search I had a problem whereby some users received zero results when searching SharePoint content.

In this configuration SharePoint was in one forest (A) and the users who got zero results were in another forest (B).  Users in the A forest were able to search and get results.  In order to resolve the issue I had to convert the SharePoint Search Service Application to store the SharePoint ACLs in Claims format.

To convert the SharePoint Search Service Application open the SharePoint Management Shell and run Get-SPServiceApplication.  Copy the ID of the Search Service Application.

SPSearchClaims1

 

Now run the code below replacing %SearchServiceID% with your Search Service Application ID.

$SearchApp = Get-SPServiceApplication %SearchServiceID%
$SearchApp.setproperty(“ForceClaimACLs”, 1)

Run a full crawl and users in the other forest will get search results.

Renaming SharePoint Taxonomy Terms

If you rename a taxonomy term in SharePoint, the change doesn’t take effect instantly.  You have to wait for the SharePoint Timer Job “Taxonomy Update Scheduler” to run, which by default is every 1 hour.

If you want the change to take place immediately, or to change the job schedule, open Central Administration -> Monitoring -> Review job definitions.  Scroll through the jobs until you reach the Taxonomy Update Schedule for the web application where you made the change.  Click on the job title and click Run Now, or reschedule the job.

Upgrading SharePoint 2010 To SharePoint 2013 Part 2

These are notes from my first upgrade of SharePoint 2010 to SharePoint 2013.  The purpose of the upgrade is to carry out an initial test upgrade to find any issues etc.  I’m not replicating the environment in terms of server roles etc. everything is installed on one server with local SQL.  I followed the steps outlined here: http://technet.microsoft.com/en-us/library/cc303436.aspx

This is part 2, part 1 can be found here, part 2 here, part 3 here, part 4 here and part 5 here.

Copy databases to the new farm for upgrade to SharePoint 2013

Reference: http://technet.microsoft.com/en-us/library/jj839720.aspx

As this is a test upgrade, don’t set the databases to read-only.

Backup all the SharePoint 2010 content databases and the databases for any service applications you’re going to upgrade.  See part 1 for upgradeable service applications.

Copy the SharePoint 2010 database backups to the SharePoint 2013 SQL server.

Restore the SharePoint 2010 database backups on the SharePoint 2013 SQL server.

If upgrading SQL server versions, change the database compatibility level to match the new SQL server version.

Customising A SharePoint Display Form To Remove A Field

Clicking View Properties on a SharePoint list item loads a display form which shows all the list columns and their values.  I needed to remove one of the list columns from a display form and in this post I’ll show you how I did it.  I’m going to remove the specific image column in the screenshot below.
HideField1

In SharePoint Designer open the list you want to customise.  In the Forms section click New.

HideField2

Provide a file name and select the form type you want to create.  Here I’m creating a display item form.  I’ve chosen to set the new form as the default display form as I want to override the default form.

HideField3

In the Forms section right-click on the form and select Edit File in Advanced Mode.

HideField4

Switch to code view and select the HTML for the row you want to remove. Each row is displayed withing <tr></tr> table row tags.  In the screenshot below I’ve selected the row which displays the jurisdiction column.  Once you’ve selected the correct row click delete.

HideField5

Save your changes.  When you click on the list item and select view properties you’ll see that the row has been removed.

HideField6

If your list contains attachments please be aware of the following bug whereby attachments aren’t displayed in the custom display form.  See the KB article for more information and a workaround.

“SharePoint Designer created display forms do not display attachments when present.”

http://support.microsoft.com/kb/2590041

User License Enforcement In SharePoint 2013

One of the great features of SharePoint 2013 is User License Enforcement.  This enables you to map users, or Active Directory security groups to a SharePoint license level.

User License Enforcement is disabled by default and is dependent on Claims authentication.  However, Claims authentication is the default in SharePoint 2013 http://technet.microsoft.com/en-us/library/cc262350.aspx.

To enable User License Enforcement, open the SharePoint 2013 Management Shell and type Enable-SPUserLicensing.  To confirm User Licensing is enabled type Get-SPUserLicensing.  Enabled, True should be the output if it’s enabled.

To map an Active Directory security group to a SharePoint Enterprise license enter

$a = New-SPUserLicenseMapping -SecurityGroup “yoursecuritygroup” -License Enterprise

Add-SPUserLicenseMapping $a

Replace Enterprise with either “Standard”, “Project”, “DUET”, or “WAC” depending on the license level you wish to enable.  Project is for Office Project Server, DUET is for SAP and WAC is for edit rights in Office Web Apps.

In the screenshot below I’ve mapped two Active Directory security groups to different license levels, one to an Enterprise license and one to a Standard license.

UserLicensing1

Once you have configured the license mapping, enter Get-SPUserLicenseMapping to view the mappings.

UserLicensing2

Once the User License Enforcement has been configured users will see a different view dependent on their license level.  Below you can see a user mapped to an Enterprise license can create sites, such as Business Intelligence Center.

UserLicensing3

The user in the screenshot below is mapped to a Standard license and has a different set of site creation options.

UserLicensing4

If a user with a Standard license accesses a page containing an Enterprise level web part they may see an error relating to a lack of license.

UserLicensing5

For a full list of licensing PowerShell cmdlets visit the TechNet site http://technet.microsoft.com/en-us/library/jj219609.aspx

User Context Sensitive Searching In SharePoint 2013 Part 2

This is the second post in a two part series.  The purpose of this two part series is to demonstrate how you can alter SharePoint 2013 search results based upon the current user.  The example I’ll use here is promoting specific search results to the top of the search result list based on the user’s department in Active Directory.  This feature is known as User Segmentation and the method I describe is my take on the information and code available here http://blogs.technet.com/b/speschka/archive/2012/12/02/using-user-context-aka-as-segmentation-in-search-with-sharepoint-2013.aspx and here http://msdn.microsoft.com/en-us/library/jj870831.aspx

In this post I’ll show the user properties within SharePoint 2013 for two test users.  Each user has a different department and will see the search results ordered differently.

UCSS1 UCSS2

Once the users have been imported from Active Directory, the properties are displayed in the User Profile Service Application.

UCSS3 UCSS4

During the user import process a taxonomy is automatically created to hold the department values.  This is where the web part looks up the user’s department and retrieves the term tag ID.  You can see a term has been created for each department.  You can open the Managed Metadata Service from Site Settings, or from the Service Application.

UCSS5

Add the custom web part to a SharePoint web part page.  The link to download the Visual Studio solution and installation instructions are in the previous post.

UCSS6

Edit the web part properties and click on Change query.  On the basics tab select your search source and enter your search term.  Click Test to run the query, results will appear in the right-hand pane.  Click OK to save changes.UCSS7

On the web part properties ensure that result table is set to RelevantResults.  Save you changes to the page.

UCSS8

At this point the web part is returning same results as the standard Content Search Web Part.  The next step is to create query rules to alter the search results based on the user’s department.

Navigate to your Search Service Application and open Query Rules.

UCSS10

Select Local SharePoint Results and click New Query Rule.  This will create a query rule that will fire for any search of local SharePoint content.

UCSS11

Enter a rule name, expand Context, then under “Query is performed by these user segments” select “One of these user segments” and click Add User Segment.  Here we will select the department for which we want the rule to fire.

UCSS12Enter a title for the segment, e.g. IT Services and click add user segment term.  Expand the Managed Metadata Service, then navigate to the Department taxonomy and select the desired department, click Save.

UCSS13The query rule should now look as follows.

UCSS14Under Query Conditions click Remove Condition as we want the query rule to fire for any search term.

UCSS15In the Actions section click Change ranked results by changing the query.  Here we will promote results with a certain keyword in their title.

UCSS16In order to experiment with the query rule you need to have enabled the Search Server Web Parts and Templates feature under Site Settings, Site Collection Features in the Central Administration web site.  If this feature hasn’t already been enabled, you will receive an error when testing the query.  If this happens, cancel the Build Your Query wizard, enable the feature and return here to continue the process.

When the Build Your Query wizard loads enter a search term in the Query text box and click Test query.  The results in the search result preview pane show the search results before we begin to alter the ranking.

UCSS17Next, click onto the Sorting tab.  Click Set top sorting level to rank, then click Add dynamic ordering rule.

UCSS18In this example I’m going to promote search results with the word “health” in the title to the top of the search results.

UCSS19Click onto the Test tab to preview the changes the dynamic ordering rule has made to the search result ranking.  You can see the result with “health” in the title has been promoted to the top of the search results.

UCSS20Remove your test query term from the Basics tab, click Ok, followed by Save to save your query rule.  For this example I repeated the process to create a second rule.  This rule fires for users in the Finance department and promotes results with the keyword “tax” to the top of the search results.

Below are three screenshots.  Each screenshot shows the same SharePoint page with the customised web part at the top and a standard Content Search Web Part at the bottom viewed as a different user.  You can see that the query rule using user segmentation only works on the custom web part.  The first screenshot is for a user that’s not in IT Services, or Finance and you can see the search results for both web parts are the same.  The second screenshot is for a user in IT Services and you can see the results with “health” in the title have been promoted.  The final screenshot is for a user in the Finance department and you can see the results with “tax” in the title have been promoted.

UCSS21UCSS22

UCSS23

The process I have described in this two part series is just an example.  You can adapt the web part and query rules to meet you own requirements.  Query rules are extremely powerful, yet easy to use.  I hope this two part series has give you some ideas you can implement in your environment.

My Sites Site Collection Has NoCrawl Flag Set

Following the creation of a My Sites site collection I attempted to search for a user, but no results were returned.  I checked the search service crawl log and saw that the crawl of the My Sites site collection had failed due to “The item and all items under it will not be crawled because the owner has set the NoCrawl flag to prevent it from being searchable”.

MySitesNoCrawl

In order to remove the NoCrawl flag, open the offending site as a site administrator.  Click on the URL in the error to open the site.  Open Site settings and navigate to the Search section.  Click on Search and offline availability.

MySitesNoCrawl2

Change Allow this site to appear in search results to Yes and save your changes.  Now re-crawl the site.

MySitesNoCrawl3

Incorrect Permissions For Central Administration Following Initial SharePoint 2013 Installation

Following the installation of a SharePoint 2013 environment I had an issue where Farm Administration security settings hadn’t been correctly applied.  Even though my SharePoint setup user account was listed in the Farm Administrators group and was a local administrator, many options were missing from the Central Administration site.  Some of the missing options included manage services on server and I was unable to create new service applications.

In order to correct the permissions, I re-ran the SharePoint 2013 Products Configuration Wizard.  When running the wizard I left all the options as they were.  Once the wizard had completed the permissions had been set correctly and Central Administration displayed all the options correctly.