IIS application pool and domain indentites

Follow these steps to specify and non standard identity for an IIS application pool. For this example I will use the account domain\WebUser

1. In Administrative tools open the Local Security Policy program. And find the Log on as service policy in Local Policies, User Rights Assignment. Click properties and add the user domain\WebUser
2. Open Windows explorer and go to C:\Windows\Temp. Open the Sharing and Security and add the user to the security tab. Grant the user enough rights to read and write files
3. Open a command prompt and change to c:\windows\microsoft.net\Framework\v2.0.50722. Run aspnet_regiis.exe -GA domain\WebUser
4. In IIS open the properties of the application pool and go to the identity tab. Click Configurable and enter the username and password.

IIS 6 and the HTTP 401.3 error

I love it when I find a new tool to use, I love it even more when it is really useful and saves me hours of work. Recently, I had the opportunity to try out ProcMon. This is what happened.

Our test web server started returning HTTP 401.3 errors. The cause was quick to find; the permissions on the root website folder had been changed and the IIS accounts were missing. So the fix appeared simple, re-apply the permissions and they will cascade all the way down the tree. I added the local IUSER account but it failed to fix the problem. I spent several hours with the MSDN documents to make sure I had the correct users and groups applied, but to no avail. I could not find a way to return the server to normal operation.

Finding the problem

The next day I felt resolved to find the problem, no more hacking around throwing users at a dialog box. For help I turned to Process Monitor (ProcMon), part of the SysInternals suite of tools. ProcMon is a superb tool for these situations. It collects all activity on the machine, showing a list file, registry and network activity. Importantly for me, it also records the result of the operation.

I fired it up, attempted to load a web page from my browser, and then stopped the trace. Tracing all the activity on a server will produce a metric ton of data; a one minute trace on my PC generates ~300,000 events. For this reason ProcMon has good filtering. You can pick from a list of events and limit by a text value. I chose to filter the list by Result, only showing those which returned ACCESS DENIED.



With the filter applied there was only one event in the list; the IUSER account was trying to access the file from my browser request. Upon checking permissions on the actual file I found that they were different to the parent. All of the IIS accounts were missing. I forced the permissions down the tree and IIS started serving pages again.

Not just any tool but the right tool

ProcMon is the star here, without it I would have found the problem but with a lot of guess work and a great deal of time. With ProcMon I could see exactly what was happening when IIS tried to serve the page. Being able to see what happens at the core of a system is essential to fault finding and having the right tool is infinitely time saving.

ASP.Net and the disappearing Session value

Sometimes errors occur that really have me scratching my head and they are usually occur when I move from my machine to the test environment.
While running through some changes I’d made to a form the behaviour of HttpSessionState became erratic, randomly returning either null or the value I had set. I fired up DebugView and captured this trace:



Here, three different threads are shown  serving the page requests and, as I would expect, only one thread is returning the value I had set.
This sounded like a configuration issue so I had a look in IIS Manager and found the application pool was configured to be a Web Garden



This now made sense as my form was using InProc sessions handling and Web Gardens behave like a single machine Web Farm, requiring a StateServer for session handling.
The solution to my problem was simple, set the value to 1 as I don’t need the resilience of a Web Garden.  If you do though Nicholas Piasecki, has a great write up here.