When writing a web application, it can be useful to store information between client requests, and this is exactly what "session state" is used for. By default, ASP.NET stores this information in the IIS process, in a mode called "InProc".

However, when you need to run a web site across a number of web servers this model can become problematic. Right now we are working with a client who needs to run the application we are building on two web servers (for redundancy). In front of these web servers is a hardware load-balancer. This particular environment does not support client affinity (i.e. your first request may go to server X, a subsequent request may go to server Y).

In this environment, we can not store the session state on the web server itself. Conveniently ASP.NET supports  two other modes - StateServer and SQLServer. This is configured in the web.config file using the <sessionstate> element.

With the StateServer option, the session state from all the servers in the farm are stored in the RAM of a single server that's running the ASP.NET State Service.

Since we did not have the option of adding another server into our client's architecture (and it would be a single point of failure), we had to go with the SQLServer option.

Setting up SQL Server for ASP.NET Session Storage

There are two options for how the session state is stored - either in tempdb or in a persisted mode in a database. The persisted mode allows sessions to persist through a SQL Server re-start. I opted for the tempdb option.

Despite being a built in part of ASP.NET, it was not obvious how to actually setup SQL Server for this - the documents indicate that you should just run aspnet_reqsql.exe without command line options, and use the wizard. However, this does not install the State stuff. You need to run aspnet_regsql.exe with the -ssadd switch.

This is what I used:

aspnet_regsql.exe -S <server> -ssadd -sstype t

(fyi aspnet_regsql.exe is in C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727.)

This will create an ASPNETDB database where the stored procs are stored, and the actual state will be stored in tempdb.

ADF Support

I did a lot of Googling and searching on EDN, and the ArcGIS Server Forums, and could not find anything that authoritatively said that the ADF would play nice with ASP.NET session state models other than "InProc". The quick answer is that it does work. We are able to run all the basic out of the box stuff without issue.