Ensuring Anonymous Access is Configured on a SharePoint 2010 Web Application using Claims Based Authentication

Creating SharePoint 2010 web applications using claims based authentication and at the same time having anonymous authentication enabled has been an inconsistent process. Sometimes it works fine and the anonymous user can browse through the site, but other times it keeps asking for credentials. I couldn’t find the reason on why it was asking for credentials. Digging on the SharePoint 2010 Powershell commands, I found the following command to get details about the authentication provider for one web application: Get-SPAuthenticationProvider.

$authprov = Get-SPAuthenticationProvider -WebApplication [web application URL] -Zone [zone]

Check the AllowAnonymous property:


To change it:

$authprov = Get-SPAuthenticationProvider -WebApplication http://yourwebapplicationurl.com -Zone Default
$authprov.AllowAnonymous = 1

List the setting again to make sure the anonymous access has been set.

See you,



CAML Designer

Liking or not, CAML is still out there and in several cases we must use it.
This CAML designer makes the task of doing CAML less traumatic for people not very familiar with the syntax or to those like me who don’t really care a lot about spending time learning CAML.

The application can be downloaded at: http://sharepoint.biwug.be/CamlDesigner/CamlDesigner.zip

The tool was created using WPF so it has a fancy UI. Very cool! Even though it is still in Beta, it worked fine form me.

Some of advantages are:

  • Options to connect using the regular API, Client Object Model and the Web Services.
  • Authenticate as the current user or providing custom credentials.
  • Nice UI with filters and view fields to generate the CAML for you.
  • Code snippets with the query you’ve built.
  • It also supports SharePoint 15 (this option I couldn’t test yet).

Code snippet from a CAML query:

It is worth to take a closer look on the tool and have it on your SharePoint utility belt! Congratulations Karine Bosch and Andy Van Steenbergen!

See you,


FAST Static Ranking

FAST has two ways of updating the ranking statistics of the documents. One is the static ranking and the other one is the dynamic ranking. The static ranking is done at crawling time, during the pipeline processing and it is going to be the same for one document on all queries executed on FAST. The dynamic ranking is done at query time using XRANK expressions based on the search terms and also on custom defined rules.

To update the ranking using the static approach you need to:

  • Add a custom relevancy field to your data source.
  • Create a new pipeline stage to update the ranking initial value.
  • Add the new pipeline stage to a pipeline.
  • Run the crawler for your data source.
  • Execute a query to test the results ranking.

Add a custom field to your data source

This field should represent the weight to be updated on the relevancy. There are several ways to calculate how a document is relevant to your usage profile. The most common way is to monitor the queries executed and the results clicked by the users and execute statistics bases on this data. Unfortunately FAST doesn’t provide an out-of-the-box way to get this type of data and update the ranking statistics. The only feature FAST ESP + Impulse provides to get data from the queries is through the Impulse Reporting feature but it doesn’t provide click tracking, only search result statistics.

Create a new pipeline stage to update the ranking initial value

To create a new pipeline stage you will need 2 files: a Python code file and a XML configuration file. This pipeline stage needs to use your custom field (customrankboost in this example) and change the value of the hwboost field. The default value for the hwboost field is 500,000. The idea is to use the custom field to apply a boost or a penalty to the hwboost field.

Examples of the files:

-Python code file.

In this code customrankboost field value is added to the hwboost field. Your implementation can do whatever you need to update the ranking initial value.

The Python file has a PY extension and should to be placed on the [FAST Root]\esp\lib\python2.3\processors\ folder.

-A XML pipeline configuration file.

The XML file should be place on the [FAST Root]\esp\etc\processors\ folder.

Add the new pipeline stage to a pipeline

After the files are in place, restart the proc_servers processes running on the FAST box and the stage will be available to be added to a FAST ESP pipeline.

Go to the FAST ESP Admin web site.

Go to the Document Processing tab and check if your pipeline stage is available.

On the Document Processing tab, edit a pipeline and add your custom stage to it.

Now your pipeline is ready to process the custom ranking field and change the initial ranking value for your documents.

Run the crawler for your data source

Make sure your custom field on your data source is filled in and run the crawler to call your pipeline with the custom ranking stage.

Execute a query to test the results ranking

After the crawl is done and the documents have been processed, execute a query and test the ranking. You should notice a change on the ranking field on the results for the documents affected by your custom field on the data source.

See you,


Measuring the Output Cache on SharePoint 2010

Output cache is a very interesting featuere on IIS, ASP.NET and also on SharePoint 2010. It helps a lot to reduce the processing time of the requests on the server and improves the number of requests your servers can serve.

Last week I wrote an article about output cache configuration, now it is time to talk about how to check if the cache is working and how it is behaving.

The out of the box Windows Performance Monitor is a tool we can use to monitor the output cache. This monitoring needs to be done on all web front end (WFE) servers because each WFE server will have its own instances of the output cache. Each web application will have one instance of the output cache.
To launch the Performance Monitor, go to the Administrative Tools menu and click on Performance Monitor. Once the tool is loaded it will display the performance counter for total CPU time by default.

Click on the green cross to selected which performance counters to add.

Go to the ASP.NET Applications category, select the counter you need and choose the IIS site for the web application you will monitor.

The output cache counters are:

Output cache entries: current number of items on the cache. It will increase every time a new page is requested and the cache doesn’t have a copy of it, so the page will get processed and cached.

Output cache hit ratio: the percentage of hits served by the cache instead of having IIS and SharePoint to process the page.

Output cache hits: number of hits server by the cache instead of having IIS and SharePoint to process the page.

Output cache misses: number of hits processed by IIS and SharePoint.

Output cache trims:

Output cache turnover rate: number of additions and removals from the cache per second. Indicates how the cache is being used and if it is effective. If it has a high turnover the cache is not being used.

It is a good idea to adjust the scale for the performance counters. They will be added to the UI in a 0.1 scale. Change it to 1.0 in order to have a better view of the variation for the values.

After you have all the counters configured you can starting testing hitting parts of the site and see how the output will behave and also the response on the browser. For the first time you request a page it should take longer to return to the browser and on the monitoring you should see a new item being added to the cache. On the next requests for the same page, it should load faster and the number of cache hits and the hits ratio should be increased.

In order to run a monitoring session and save the data you need to Data Collector Set. This is a good article on how to do it:

Create a Data Collector Set to Monitor Performance Counters

See you,


Disabling Mobile Redirection on SharePoint 2010

Disabling the mobile redirection on SharePoint 2010 might be a good solution if you don’t want mobile browsers to be redirect to the mobile pages or to

The approach we took was to change it on the web.config to override the compat.browser file. Inside the system.web node add the following tags:

<result type=”System.Web.Mobile.MobileCapabilities, System.Web.Mobile, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a”/>

It will override the isMobileDevice property for all browsers defined on the compat.browser file. It worked just fine for iPad, iPhone and Android (several versions).

More information and options on how to disable the mobile redirect can be found on this nice article from Seth Broweleit:
Three Options for Disabling the SharePoint 2010 Mobile Redirection System



See you,


SharePoint 2010 Cache Configuration

Cache is a very important feature when you think about end user response time and also server load. In my case, I was tweaking the configuration for a internet public sites in order the have a better user experience.

BLOB Cache

To improve the end user response time a good approach is to configure the BLOB Cache on the SharePoint 2010 Web Front End (WFE) servers. The BLOB cache caches files on the WFEs disk to make it faster for IIS to retrieve the files and return them to the browser. It can also send some HTTP headers telling the browser to cache the file for a certain amount of time.

We need to change the web.config to enable the BLOB cache. Find the BlobCache tag on the configuration/SharePoint node on the web.config. Here is an example of a configured Blob Cache:

<BlobCache location=”C:\BlobCache\14″ path=”\.(gif|jpg|jpeg|jpe|jfif|bmp|dib|tif|tiff|ico|png|wdp|hdp|css|js|asf|avi|flv|m4v|mov|mp3|mp4|mpeg|mpg|rm|rmvb|wma|wmv)$” maxSize=”10″ enabled=”true” max-age=”36000″ />

The location attribute defines where SharePoint is going to save the cached files.

The path attribute represents a regex defining the file extensions to be cached.

The maxSize attribute defines the maximum size of the cache in Giga bytes.

The enabled attribute defines if the cache is enabled.

The max-age attribute defines the maximum time in seconds the browsers can cache the files locally and avoid making requests for these file to the server. This setting affect how the users’ browser cache the files defined on the path attribute.

Output Cache

Another cache feature available on SharePoint 2010 is the Output Cache.

The Output Cache caches the HTML output for the pages processed by SharePoint. This cache improves the server processing time for the cache pages since IIS doesn’t need to call SharePoint and wait for the page to be processed. It just gets the cached copy and send the HTML back to the browser. The Output Cache is configured per Site Collection.

First we need to make sure the cache profile is configured in the way we need.

Go to the Site Settings page, then to Site Collection Administration and then to Site Collection Cache Profiles.

The default cache profiles are listed. I’ll check if the Public Internet one is alright for my needs.

In my case I’ll need a few tweaks on the cache profile configuration:

  • Check for changes: This setting needs to be Yes in order for the cache to items in the cache if they changed before the duration of the cache. It affects performance but it is a good option to make sure Content Managers have their content showing up on the site as soon as they approve it.
  • Vary by query string parameters: Since we have several dynamic pages which receive parameters by query string and produce different HTML in the output we need to specify the query string parameter. The value of the parameter should be * since the names of the parameters vary a lot.

My new cache profile looks like this:

After your cache profile is ready, you should go to the Site Settings page, then to Site Collection Administration and then to Site Collection Output Cache.

Make sure you enable the Output Cache and select the cache profile you just created.


Now you just need to recycle your app pools and start testing the cache. Both caches can be tested in HTTP monitoring tools such as FiddlerHTTP Watch, IE Developer Tools or Chrome Developer Tools.

Two important notes on testing:

  • If you hit F5 on a page, your browser will sent HTTP headers to the server telling it to ignore any cache. The best way to test is navigating thru the site and checking which page and assets (images, js, css files) are called or cached.
  • If you configure your browser to always request the most current version of the page, the BLOB cache will not work on the client side.


More references about caching can be found at:

SharePoint BlobCache Explained
Digging Deeper into the 2010 Caching Options: Part 1
Digging Deeper into the 2010 Caching Options: Part 2
Client-Server Interactions and the max-age Attribute with SharePoint BLOB Caching
BLOB Cache, HTTP 304 Results and F5/Refresh

See you,


HTTP Handlers and SharePoint 2010

Trying to debug an error on a HTTP handler, we got the following error message:

Parser Error Message: Could not create type ‘MyNameSpace.MyClass’.

The HTTP handler directive on the ASHX file looked like this:

<%@ WebHandler Class="MyNameSpace.MyClass" %>

I found the solution for this issue at http://sharepoint.stackexchange.com/questions/19928/sharepoint-2010-and-ashx-handler.

The explanation:

Since we are using SharePoint 2010, the HTTP handler was deployed to the LAYOUTS folder. The trick here is that SharePoint needs to load all its referenced assemblies from the GAC and in this case the assembly was in the GAC but we were not referencing the FQDN of the assembly.

The ASHX file should look like this:

<%@ WebHandler Class="MyNameSpace.MyClass, MyAssembly, Version=, Culture=neutral, PublicKeyToken=7c8e2c3ef53023ee" %>

After updating the ASHX file the error was solved.

See you,