SharePoint 2010: Usage files are not deleted, causing timer service problems.

On a SharePoint Server 2010 server, the Usage Provider (.usage) files are not deleted from the file system. Additionally, the .usage files keep growing.


The ULS logs are filled with the below errors :


Trace Management Service unable to delete file ‘D:\APPS\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS\IPW-SPWFE01-20160328-1257.usage’.  Error 00000020


To clear the old .usage files from the file system, I had to restart the SharePoint Timer Services. The .usage files were not getting automatically deleted and this is a known issue.


MS recommends the below action to fix this:

  1. Installing December 2013 CU for SharePoint 2010 (I would not recommend this )
  2. Set up a scheduled task to manually recycle the timer service (at least) once a day — every 4 to 6 hours would be better. 


You can use a PowerShell command like this to recycle the service:

restart-service -Name SPTimerV4


Then you just need to set up a scheduled task to run it every 6 hours on every SharePoint server in the farm.

When the timer service is manually recycled, the open handles to the .usage files are released, and they will be automatically deleted when the next instance of the Usage Data Import timer job runs (by default every 30 minutes).


There should be no need to manually delete the files or restart the services.



fix vertical scroll issues + SP 2010

var elmRibbon=GetCachedElement(“s4-ribbonrow”);

var elmWorkspace=GetCachedElement(“s4-workspace”);

var    vph=GetViewportHeight();

var newWorkspaceHeight=vph – elmRibbon.offsetHeight – AbsTop(elmRibbon);





Source –

Hide a custom webpart

Open the web-part in notepad….


From true to false as below.


Show / hide fields on Edit Form




// wait for the window to load

$(document).ready(function () {


var fields = SPUtility.GetSPFields();

for (fieldName in fields) {

// do something with the field

if(fieldName == “Review On” || fieldName == “Approved By” || fieldName == “Approval Date” || fieldName == “Approved Version” || fieldName == “Current Version” )







How do I filter a document library view to show the contents of a subfolder?

With SharePoint Designer you can edit the CAML of your XSLT List View.

If you set the Scope attribute of the View element to Recursive or RecursiveAll, which returns all Files and Folders, you can filter the documents by FileDirRef:



<FieldRef Name=’FileDirRef’ />

<Value Type=’Lookup’>MyFolder</Value>



This returns all documents which contain the string ‘MyFolder’ in their path.

Posted at :

How to create rich HTML email message in Sharepoint Designer 2010 workflow

First create your HTML in any other HTML editing tool (NOTE: Try to avoid spacing & <br/>’s )

2. Then open your workflow in SPD 2010

3. Add “Send email” workflow action from ribbon

4. Keep “Send Email” action selected/highlighted

5. Then navigate to ribbon and select advanced properties

6. Select last option Body

7. Click on the button (3 dotted button) to open the text pad

8. paste your html

9. Click OK and open the action from workflow step

10. Then add your lookups and test it.

Done !

Browser Back Button History Not Working with SharePoint Managed Metadata links

Browser Back Button History Not Working with SharePoint Managed Metadata links.

A client reported user grief in that when users clicked from static hyperlinks they had put on their SharePoint team site page Content Editor Web Part, which pointed to specific nodes on a Managed Metadata treeview menu, subsequent clicks of the browsers back button would not have the normal effect of returning to them from whence they came. In fact the back button in the browser really does nothing at all.

The reason is there is a # symbol at the tail end of the URL. The # symbol is traditionally used to denote anchor tags in HTML. In modern web applications it’s commonly used in AJAX techniques .

In the particular case of links to the nodes in the left-hand managed metadata menu, those links include a tag#serverfilter  with a bunch of parameters after that that tell the web browser to go to the specific node in the menu. Unfortunately, as the client discovered, Internet Explorer and some other browsers do not handle browser history normally when navigating via the # tag. Even though you are apparently loading new page content, the browser disagrees, because you are not actually loading an entire new web page – just a dynamic portion of Javascript that is displaying new content.

An example of such a URL is below – the offending #serverfilter and the variables it delivers are bolded.


One of the biggest problems when using AJAX in web development has always been maintaining application state. In a Javascript heavy site (like SharePoint) one might want to do all sorts of things that alter the state of the user experience. For example, opening up modal dialogs (popups) over the page to request input from the user, etc. Because these state changes are occurring only with Javascript the browser is technically unaware of what is going on. If the user decides to hit the back button thinking they are just going back to before they opened a popup, they’ll be surprised when it takes them several steps backward to the last point where their browser actually made a full request. Similar issues occur when they refresh the page. The dynamic state is totally blown away and a new page request is made.

Since the basics of web navigation have always implied that a “new page” is what forms a single unit of web history, you’re not getting the back action as expected when direct linking to items in the Managed Metadata menu tree.  Unfortunately this is not a SharePoint-specific problem, it is endemic with lot’s of newer web applications online today from various vendors.

While I personally have coded workarounds for this type of problem in the past, it was for very specific, simple application scenarios (not like the huge complexity of SharePoint). In the case of out-of-the-box (mis)behavior like this I would advise simply that this unexpected back button behavior is the way it is and that users will have to adapt to selective back button history response (as they probably have on other online web applications).


Written by Keith Tuomi on. Posted in Internet ExplorerManaged MetadataSharePoint 2010