Using Windows Azure tables to persist session data

Being able to store session data is arguably one of the reasons that the Web features the dynamic applications we all use every day.  If it wasn’t for the session we would have a fairly boring static Web experience.

Windows Azure, being built on top of Windows Server 2008, allows ASP.Net developers to utilise all the session features of IIS.  Additionally the developer can extend these options with the Windows Azure table storage to cheaply and easily persist storage of session data in the Cloud.

Session storage for Windows Azure

The scalability of Windows Azure means that you are going to have at least a couple of web roles and possibly even tens or hundreds of web roles for busy sites.  All these individual web roles need access to a central session store, the best place to put each user’s session data is in Windows Azure table storage.

The process of getting started with storing session data in the table store requires the modification of the following files.


As per normal ASP.Net web.config settings you need to modify the <sessionState> tag to point to the custom table storage provider.  Application name is the name recorded in the table when the session detail is logged, used to help identify the session.


<sessionState mode="Custom" customProvider="TableStorageSessionStateProvider">



<add name="TableStorageSessionStateProvider" type="Microsoft.Samples.ServiceHosting.AspProviders.TableStorageSessionStateProvider" applicationName="myWebAppName"/>




The sample code for the AspProviders project is availbe from Microsoft.  Search for “Windows Azure Platform Training Kit”.  Presently June 2010 is the latest release.  Looking at the TableStorageSessionStateProvider.cs namespace you can see the code still resides in the Microsoft.samples namespace, hopefully this code will be rolled up into the main Windows Azure SDK at some point in the future.

You can either include the AspProviders project into your solution or compile the DLL and include that.  Whatever you choose make sure you add it as a reference to your web role project.


The most important setting here is the “DataConnectionString”.  The AspProviders uses this to pull all the rest of the settings needed to access the table store for your account, the rest of the settings here are standard for Azure.  I’ve shown the values needed for running in the cloud environment when deployed.

<Role name="myWebAppName">

<Instances count="4" />


<Setting name="AccountName" value="yourStorageAccountName" />

<Setting name="AccountSharedKey" value="yourStorageKey" />

<Setting name="BlobStorageEndpoint" value=" " />

<Setting name="QueueStorageEndpoint" value=" " />

<Setting name="TableStorageEndpoint" value=" " />

<Setting name="allowInsecureRemoteEndpoints" value="false" />

<Setting name="DataConnectionString" value="DefaultEndpointsProtocol=https; AccountName=yourStorageAccountName; AccountKey=yourStorageSharedKey " />



At this point you will need to add the setting name keys into your ServiceDefinition.csdef or your will get a build error.


You will need to set the configuration setting for the Azure CloudStorageAccount before you try and access the table storage.  This is best done in the Global.asax of the web role project

CloudStorageAccount.SetConfigurationSettingPublisher((configName, configSetter) => configSetter(RoleEnvironment.GetConfigurationSettingValue(configName)));

If all has gone to plan you can run your application and connect to the live Windows Azure services.  Using a tool like Cerebrata Cloud Storage Studio you can look in your table store and see that a new table will be automatically created for you called “session”.  If you perform a task requiring state in your application you should see serialised version of your session data stored in the table.

8 thoughts on “Using Windows Azure tables to persist session data

  1. Hi Niall,

    Thanks for the post. I am following your article to use Table starage as Session. I am not clear where i should put the code for Global.asax file. And also where you get CloudStorageAccount class?

    1. Hi Hasitha,

      The code for the global.asax.cs file should live inside the Application_Start method. Also to get access to the CloudStorageAccount class you will need to add references to the following in your web application project.


      Also you will need to add the following to your using section of the global.asax.cs

      using System;
      using Microsoft.WindowsAzure;
      using Microsoft.WindowsAzure.ServiceRuntime;

      I hope this helps


  2. Niall,

    when you say “The most important setting here is the “DataConnectionString”. ” is this true. I thought that the aspproviders only look for the AccountName,EndPoints and sharedKey.

    Also, do the providers look for these values in both the web config and the ServiceConfiguration files.

    If So, where should they be put(Best Practise).


    1. Hi Noel,

      The DataConnectionString is important as most examples in the beta phase of Azures life left them off and its essential to retrieve the Azure account settings when using functions like this:

      account = CloudStorageAccount.FromConfigurationSetting(“DataConnectionString”);

      Of course the Account name, endpoints and the shared key are all essential but it can be easy to overlook the DataConnectionString too.

      These values in the example only need to exist in the ServiceConfiguration.cscfg and ServiceDefinition.csdef of the Azure project not the individual site web.config.

      I hope this helps and thanks for highlighting these points.


  3. Niall,

    Thank you for this quick start guide. Most helpful to get Table-based sessions up and running in only a few minutes. One challenge however is that each time you add something to the session it appears to create a new BLOB, leaving the old one in the blob-store AND it doesn’t appear to clear them up when the session expires.

    With sites that write many entries to the session, and many sessions expiring the Cloud Storage bill is likely to get a little daunting.

    Short of running a worker process to poll the table occasionally to look for and clear out expired sessions, is there any way you’re aware of to enable the Table Storage Session Provider to clean up behind itself?

    Any thoughts / pointers would be much appreciated before we embark on garbage collecting the Table and BLOB storage ourselves.

    1. Hi Matt,

      I’m glad you found the blog helpful. Unfortunately I’m not actively working with Windows Azure right now so I don’t have up to date information on how things have moved on.

      When we ran a small project in the early days of Azure we did exactly as you suggested, using a worker process to delete blob entries more than 24 hours old. Thankfully at the time we were on an all inclusive package so cost wasn’t so much of an issue.

      I’m surprised there are not more modern examples of table based session storage with Azure, especially given the speed of development that Microsoft has given the Azure platform. I know that’s not much help but I wish you luck improving the method.


Leave a Reply

Your email address will not be published. Required fields are marked *