My Blog: 2010 in review

The stats helper monkeys at mulled over how this blog did in 2010, and here’s a high level summary of its overall blog health:

Healthy blog!

The Blog-Health-o-Meter™ reads Wow.

Crunchy numbers

Featured image

About 3 million people visit the Taj Mahal every year. This blog was viewed about 58,000 times in 2010. If it were the Taj Mahal, it would take about 7 days for that many people to see it.


In 2010, there were 7 new posts, growing the total archive of this blog to 189 posts. There was 1 picture uploaded, taking a total of 24kb.

The busiest day of the year was September 14th with 308 views. The most popular post that day was Add Custom ASPX Pages or ASP .Net Pages in SharePoint.

Where did they come from?

The top referring sites in 2010 were,,,, and

Some visitors came searching, mostly for sharepoint architecture diagram, moss architecture, sharepoint 2010 architecture diagram, moss architecture diagram, and sgen.exe exited with code 1.

Attractions in 2010

These are the posts and pages that got the most views in 2010.


Add Custom ASPX Pages or ASP .Net Pages in SharePoint February 2008


MOSS WSS Components Architecture in a single diagram February 2008


InfoPath cannot connect to a data source when viewed in browser – Cross Domain Issues – Universal Data Connection March 2008


Using stsadm to deploy, upgrade, update InfoPath Forms Templates with Managed code behind March 2008


SharePoint: Delete / Purge / Remove Orphaned Sites or Site Collections November 2007


SharePoint site with InfoPath forms and Random session lost issue

We were able to fix a sticky issue which was bugging us since a long time. Its a sporadic issue and its always interesting to debug issues like these.

Issue details: This is in reference to SharePoint portal site which uses InfoPath Forms extensively which was extended into multiple zones (intranet, extranet) with dual authentication (AD and LDAP with MFA/FBA). The issue with the site was that it was losing the session randomly while the user is actively working on it. The random time period could be anywhere from 8 mins to 20mins or more.

Debugging the issue: We started facing this issue in our (staging/no-harm) environment and later we realized it wasn’t isolated to a specific environment as this was reproducible in our QA, UAT etc environments too. Changing or increasing the session timeout value was certainly not having any kind of effect on the random timeout issue. That was ruled out of the picture. I started looking into SharePoint logs, IIS logs and Application specific event logs, still hitting the wall.

With the infrastructure we have one hits the SharePoint site through a multi-factored authenticated (MFA) site which is basically a single point of entry for external partners. This MFA site authenticates using SiteMinder/LDAP. The extranet forms based authenticated (FBA) based SharePoint site picks up the user context from this site without prompting the user to log in again.  The next step was pushing this issue to the MFA/Application-security team to verify if all is well from their side.  Yes, everything remains the same and fine on their side.

We have been using Fiddler/HTTPWatcher to track the http headers exchanged while trying to reproduce the session lost issue. After tracking down the HTTP headers while reproducing the session lost I found that the ASP.NET_SessionId cookie which was supposed to be sent in the header is  not being sent at that moment and thus session is lost.

Below is a small useful excerpt from a blog link:

How a web application uses cookies to maintain session state is simple: the application framework simply associates all the runtime state of the application with the ID (i.e. SessionID) and makes sure to send that ID with a Set-Cookie on the initial HTTP response, and whenever the web browser makes a subsquent request to the application’s URL namespace, the application framework inspects the cookie header for an ID and if it is found, look up all of the associated runtime state and continue processing the web application with that state. Good application frameworks would also control the time period of validity for this runtime state via something like Session

But now the question arises about what and why this is happening? Why does the browser stop sending the ASP.NET_SessionId cookie randomly?

One thing that I noticed is that there are multiple cookies that are maintained and the number of cookies are increasing for each page refresh or access. On close observation we narrowed it down that on page access that has an XMLFormView control which contains the InfoPath form is adding 2 cookies which look something like below:

2877de91-2fc1-48bd-b134-7e5480751aa1_sel    Sent        /    (Session)

2d12188c-1f35-427c-b741-634acde50a8e_pb    Sent    0    /    (Session)

I couldn’t find any good documentation/links on how InfoPath Forms Services use cookies especially the above ones. However, the _sel and _pb represents the selection and postback cookies.

As the number of cookies are increasing and as it exceeds the browser limitation of max 20 cookies per domain the ASP.NET_SessionId is dropped and thus the session is lost.  Here is the copy one of the lines from Microsoft KB Article:

If a Web application uses more than 19 custom cookies, ASP session state may be lost.

In order to conclude this I wrote a quick and dirty (my favorite) java script solution to remove the InfoPath form cookies that are not used or empty and retain only the latest 2 cookies. With this script plugged into the master page the session lost issue never happened again.

I uploaded the script to SkyDrive. Here is the link to the folder and you will see a file named: CookieCleanupScript.txt!6040

Synch Options from Microsoft Excel to SharePoint

Depending on the business case one of the following options should be a valid one.  It depends on the infrastructure too. There are a few limitations, variations and difference in concept depending on the requirements, for example if the use case involves only Excel 2003 usage, the process of porting data from Excel to SharePoint concept is called Publishing, where as if its Excel 2007, the process is keyed as Exporting. This difference is because

Excel 2003, out of the box (OOTB) it has the ability to synch 2 way with SharePoint.

Excel 2007, OOTB has the ability to do only 1 way synch. Although Microsoft released a add in to make 2 way synch possible.

In either case once the export/publishing is done the data in SharePoint should be considered as the master data.

1. MS Office Excel 2003 – 2 way synch is possible [Publish to SharePoint]

2. MS Office Excel 2007 – 1 way synch. (with add in 2 way synch is possible) [Export to SharePoint] (Addin 2 way synch) One way synch (SP to Excel)

3. General

4. Publishing Excel Workbooks to SharePoint so that users without MS Office can access complex spreadsheets in Browser

Workaround: Format SharePoint number column to remove commas

Let’s say you have a column named “TicketNumber” of number type in your list. By default SharePoint formats it to show with commas. If your requirement is not to show those comma’s then here is a workaround.

Create another column of  ‘Calculated’ column type and set the formula as follows:


Ex: =TEXT([TicketNumber],”0″)

And then use the calculated column in place of your original column for display purposes.

Versioning SharePoint Workflow

Lets say you developed and deployed a complex state workflow using Visual Studio with WSPBuilder add on. Things are going smooth and the business came up with new set of requirements/changes to the workflow. What would be your approach?

You cannot just modify/update the Visual Studio project according to the new requirements and deploy it. This might entirely mess up your existing workflow items, especially the workflow instances which are in waiting mode i.e waiting for an external event are serialized and persisted in the SharePoint content database. When you deploy your modified workflow and when the workflow engine tries to deserialize the existing instance from DB it might fail as it cannot match with the updated workflow dll and thus end up halting the workflow process.

There is no out of the box solution to maintain versions of the same workflow. However there are workarounds to it. Please read this blog entry which is widely accepted and implemented.

The basic idea is to create a complete new workflow project with different name and solution id. Then deploy it and attach to the same doc. library. Then using the doc. library workflow settings select “no instances” for the old workflow and “allow” for the new workflow. This will attach the new workflow for any new items and the existings items will still continue with the old workflow.

**If you are using InfoPath form to build the workflow task form then make sure that you have a new version of the infopath form with a different name.

Follow the below steps to easily make a new version of the existing workflow project:

  1. Create a new project based on the WSPBuilder with Workflow project template and name it as same as your old workflow name appended with the version number. Ex. MyCompany.StateWorkflow.Ver2
  2. Now right click the project and new state workflow project item from the WSPbuilder items. Provide the same name as exists in the old workflow project so that it creates the .CS and .Designer files with the same name.
  3. Copy the .CS and .Designer files from your old workflow project to the new project replacing the newly created ones.
  4. Compile and make sure the project is having no build errors.  Its almost done.
  5. Next steps would be to modify the workflow/elements xml files to bring it up to speed with the old workflow xml file entries. Also, make a new copy of the InfoPath task form name it appending the version number and copy to the new project structure.

The above may not apply for everyone and may not apply for SharePoint 2010 workflow. I documented the above steps so that I can come back and follow them whenever required.

SSRS: Logon failed. (rsLogonFailed) or Logon failure: the user has not been granted the requested logon type at this computer

Logon failed. (rsLogonFailed)

Logon failure: the user has not been granted the requested logon type at this computer. (Exception from HRESULT: 0x80070569)


Add the user account which you provided for the ‘Execution Account’ in the Reporting Services Configuration Manager to the local Administrators group.  By default the ‘Administrators’ group is added the ‘Content Manager’ role by SSRS so when you add the execution account to the administrator you are giving that user the ‘Content Manager’ role/permission. I am not sure neither if this is the best solution nor the only solution for the above error. The solution might vary on the setup and environment.