SharePoint 2013: troubleshooting Popularity Trends

Popularity Trends in SharePoint 2013 replace the Analytics in SharePoint 2010. Now it is part of the search component.

Keep in mind that after you visit a page, the counter are not updated in real-time, as results come after 2 days after the midnight (so in the end you get your results on your third day).

If still you get 0 results, there is an excellent troubleshooting guide: Troubleshooting SharePoint 2013 Web Analytics.

It's worth saying that the data is saved in the SharePoint_ServiceApps_UsageAndHealth database (or equivalent name), view dbo.RequestUsage, to be selected with (NOLOCK) clause.

A script fixing event receivers on page is described in Sharepoint 2013 Analytics Reports empty.

And how get data programmatically: How to get Search Analytics Reports programmatically in SharePoint 2013.

SharePoint 2013 and SharePoint Online: deploying branding artifacts

It is possible to deploy branding artifacts, like master page, page layouts, css and so on, in SharePoint using the client side object model, without the need of a farm solution.

An old article, but still valid for content and explanation, is Self-Service Site Provisioning using Apps for SharePoint 2013.

Up-to-date solutions, containing a lot of sample and reusable code, can be found in the Office365 Developer Patterns and Practices.

SharePoint 2013: Duplicate entries in People Picker with ADFS authentication

In SharePoint 2013, there are two possible reasons why you can get duplicate results in your people picker searches.

The first one is that maybe there are multiple types of authentications enabled for the SharePoint zone, for example Claims and Active Directory.
In this case you should follow the article Configuring a Custom Claims Provider to be Used only on Select Zones in SharePoint 2010.

In the second case, maybe there are SAML claims users. The behavior is by design, because there is no function to get a list of users using SAML claims, so SharePoint just accepts whatever we type and assumes we are typing the correct value.  There are two values that it is looking for, either the email address (which is the identifier claim in this configuration) or a role claim, and this gives duplicate results.

The solution then is to create a custom claim provider. In CodePlex it's possible to find the pre-built solution LDAP/AD Claims Provider For SharePoint 2013 that is also suggested in the article or Kirk Evans reported below. I have never tried it directly, but it seems a pre-build solution that needs to be deployed and eventually configured.

A few links about the custom claim provider:

Finally, the articles below are useful if you really want to write a really custom claim provider written by yourself:

Visual Studio 2013: how test the performance of the html UI

As new solutions are pushing more and more the html UI, with various JavaScript and AJAX calls to complicate the scenario, analyzing the performance of the UI requires new tools.

For this, in Visual Studio 2013 you can find the HTML UI Responsiveness Profiler.

Here a few links on this topic:

SharePoint: how retrieve the user manager in an approval workflow

In SharePoint it's quite easy to find the manager of a user, for example in an approval workflow.

Here are some links explaining how to do that:

SharePoint: how deploy lists or document libraries with a predefined folder structure via CAML

In SharePoint, it's possible to deploy lists and libraries with a predefined folder structure via CAML.

Simply, in the ListInstance tag, add Row tags (inside a global Rows parent tag), as shown in Provision a folder inside a document library.

It's also possible to create nested folders using the FileDirRef tag.

For example, the xml below creates one folder (FolderA) with a nested folder (FolderBinA) with a nested folder (FolderCinB).

<?xml version="1.0" encoding="utf-8"?>

<Elements xmlns="">

<ListInstance FeatureId="{00bfea71-e717-4e80-aa17-d0c71b360101}" TemplateType="101" Title="DamianoDocLib" Description="" Url="DamianoDocLib" CustomSchema="Files\DamianoDocLib\Schema.xml" HyperlinkBaseUrl="http://test_sp" RootWebOnly="FALSE" xmlns="">




<Field Name="ID">1</Field>

<Field Name="ContentTypeId">0x0120003CCC413DD038BE4CAB81E6C6F4C08742</Field>

<Field Name="_ModerationStatus">0</Field>

<Field Name="FSObjType">1</Field>

<Field Name="FileLeafRef">FolderA</Field>

<Field Name="MetaInfo">1;#</Field>

<Field Name="Order">100.000000000000</Field>

<Field Name="Title">FolderA</Field>



<Field Name="ID">2</Field>

<Field Name="ContentTypeId">0x0120003CCC413DD038BE4CAB81E6C6F4C08742</Field>

<Field Name="_ModerationStatus">0</Field>

<Field Name="FileDirRef">FolderA</Field>

<Field Name="FSObjType">1</Field>

<Field Name="FileLeafRef">FolderBinA</Field>

<Field Name="MetaInfo">2;#</Field>

<Field Name="Order">200.000000000000</Field>

<Field Name="Title">FolderBinA</Field>



<Field Name="ID">3</Field>

<Field Name="ContentTypeId">0x0120003CCC413DD038BE4CAB81E6C6F4C08742</Field>

<Field Name="_ModerationStatus">0</Field>

<Field Name="FileDirRef">FolderA/FolderBinA</Field>

<Field Name="FSObjType">1</Field>

<Field Name="FileLeafRef">FolderCinB</Field>

<Field Name="MetaInfo">3;#</Field>

<Field Name="Order">300.000000000000</Field>

<Field Name="Title">FolderCinB</Field>






SharePoint 2013: Developer Dashboard

SharePoint 2013 improved the Developer Dashboard introduced in SharePoint 2010.

A few notes:
  • it's available only On Premises and not in Office 365;
  • it's enabled/disabled for all users in the farm.

The blog post Developer Dashboard in SharePoint 2013 described how to enable it:
  • create the Usage and Health Data Collection Service Application:
         New-SPUsageApplication -Name "Health and Usage Application" -DatabaseName "SP2013_Health_and_Logging_Database"
  • enable the Developer Dashboard:
         $snapin = Get-PSSnapin | Where-Object { $_.Name -eq "Microsoft.SharePoint.PowerShell" }
         if ($snapin -eq $null) {
              Write-Host "Loading SharePoint PowerShell Snapin..." -ForegroundColor Gray
              Add-PSSnapin "Microsoft.SharePoint.PowerShell"
         Write-Host "Microsoft SharePoint PowerShell Snapin loaded" -ForegroundColor Gray

         $svc = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
         $dds = $svc.DeveloperDashboardSettings
         $dds.DisplayLevel = "On"

You can filter who is able to see and use the Developer Dashboard with the RequiredPermissions property.

On my developer machine, after enabling the Developer Machine, it takes a little while before it start logging.