In SharePoint 2010 it was easy to switch between languages using the user menu within SharePoint. To switch language In SharePoint 2013 open Control Panel -> Language and click Add a language.
Once you’ve added the required languages switch between them by moving the language you want to use to the top of the list.
Close and re-open your browser for the change to be recognised.
When you install SharePoint Server 2013 the Distributed Cache service is configured to use 10% of the RAM on the server. Half of the 10% is used for caching and the other half is used for memory management. If you add RAM to the server you need to manually re-configure the Distributed Cache service to make use of the extra RAM.
To check the current RAM allocation run the command below from an elevated SharePoint 2013 Management Shell, replacing the server name as necessary.
Use-CacheCluster
Get-AFCacheHostConfiguration -ComputerName ServerName -CachePort “22233”
Calculate the new Distributed Cache service cache size for a 24 GB SharePoint Server as follows:
10% of 24 GB = 2.4 GB
Divide 2.4 GB by 2 = 1.2 GB
Convert 1.2 GB to MB = 1229 MB
Stop the Distributed Cache service on each host using Central Administration -> System Settings -> Manage services on server.
Run the command below from an elevated SharePoint 2013 Management Shell on one host at a time, replacing the cache size as necessary.
Update-SPDistributedCacheSize -CacheSizeInMB CacheSize
Start the Distributed Cache service on each host using Central Administration -> System Settings -> Manage services on server.
The SharePoint 2013 Search Query Tool can be used to query, test and debug, both SharePoint 2013 on-premise and SharePoint online search queries. It’s available free from CodePlex here. In this post I’ll show how you can use the tool to view a document’s refineable properties within SharePoint 2013 search.
For the purpose of this post I’ve uploaded a pdf to a SharePoint document library and applied a metadata value using a column called Document Type.
I’ve configured the property to be refineable and it’s visible on the search results page through a managed property called DocumentType. To find out how to do this, see my post here.
The SharePoint 2013 Search Query Tool is useful when you need to see what values are held within the search index. Open the tool and enter a search term in the Query Text box. Next, click the push pin next to Select Properties. The Path, Url, Title and Author properties will be automatically added. To show values for DocumentType managed property I added “,DocumentType” to the list (values are comma delimited). Click Run to execute the query, then open the Primary Results tab. For my test document you can see that DocumentType values are now displayed.
Using the Restricted Read permission in SharePoint 2013 it’s possible to prevent access to historical versions of documents, but it doesn’t work how I expected it to.
To enable the Restricted Read permission within a document library choose Library Settings from the ribbon. Next click Permissions for this document library. Tick the box next to the group for which you wish to enable Restricted Read and click Edit User Permissions from the ribbon.
On the screen that loads untick Read and tick Restricted Read. Click OK to close.
This is where things don’t work as I expected. I expected that when accessing the document library, the Version History option would be removed from the document properties menu, or the version history would only show the latest version. However, when a user with Restricted Read attempts to open the document library from Site Contents they receive the error “Sorry, this site hasn’t been shared with you.”
Restricted Read is described as providing view access to documents. It turns out that this is possible, but only via a direct link to documents in the library e.g. a URL on a page or search.
Following the installation of SharePoint 2010 SP2 I noticed a large number of event log errors for the Publishing Cache on web front end servers. The error was “An error occurred in the blob cache. The exception message was “The system cannot fine the file specified. (Exception from HRESULT: 0x80070002)”.
Looking deeper into the error using the ULSViewer I could see that the error was being caused by language pack files that could not be found. The files could not be found because following the installation of the language pack the Publishing Infrastructure feature had not been reactivated. The TechNet notes here state “After you install a new language pack, you must deactivate and then reactivate any language-specific features before you use the new language pack.”
In order to resolve the error I went into Site Settings -> Site collection features. I deactivated the SharePoint Server Publishing Infrastructure, then activated the feature. You need to do this out of hours and it does affect your SharePoint site while the feature is deactivated.
Following the installation of SharePoint 2010 SP2 (KB2687453) I found that the RSS viewer web part had stopped working; the web part continually showed the loading image.
After some research I discovered that the issue was introduced in SharePoint 2010 February 12, 2013 cumulative update (KB2767793). Some suggested fixes are listed on the SharePoint forums.
The first option is to add a Content Editor Web Part to any page with the RSS viewer web part and paste the JavaScript below into the web part in HTML view. Although this works it’s not a realistic work around if you have many pages with the RSS viewer web part.
<script type=”text/javascript”>
function CustomUpdateFormDigest()
{
if(window._spPageContextInfo != null)
{
var $v_2 = window._spPageContextInfo;
var $v_3 = $v_2.webServerRelativeUrl;
var $v_4 = window._spFormDigestRefreshInterval;
UpdateFormDigest($v_3, $v_4);
}
}
CustomUpdateFormDigest();
</script>
The second option is to add the above script to the SharePoint master page, but I couldn’t get this to work.
The third option is to turn off web page security validation for the web application from Central Administration -> Manage web applications. Highlight the affected web application and select General Settings from the ribbon.
Turning off web page security validation worked, but I was then unable to create any new sites or lists because I received the error “An unhandled exception occured in the Silverlight application SharePoint 2010.
I have just finished testing the August 13, 2013 cumulative update for SharePoint 2010 (KB2817570) and it appears to fix the RSS viewer issue without any side affects.
Configuring SharePoint 2010 to open search results in a new window requires editing the XSL that determines the search result display.
Open your search results page and edit the page. Choose Edit Web Part from the Search Core Results web part. Expand display properties and click on XSL Editor…
Copy and paste XSL into a tool like Notepadd++. Search for the section
<div class=”srch-Title3″>
Scroll down and add the attribute for target.
Copy and paste the XSL back into the window in SharePoint. Save and publish the page.
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.
For 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.
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.
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.
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.
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.
Following an upgrade from SharePoint 2010 to 2013 I deployed some custom web parts. When loading the page I received the error “/_CONTROLTEMPLATES/WEBPARTNAME/VisualWebPart1/VisualWebPart1UserControl.ascx” does not exist.
The error is caused by the web part looking in the \14\TEMPLATE\CONTROLTEMPLATES folder rather than \15\TEMPLATE\CONTROLTEMPLATES. Open the web part solution in Visual Studio and change the _ascxPath string. Original value below:
Change the string to include the 15 folder.
Rebuild and re-deploy the web part.
Richard Skinner 