IIS 8 introduces a new feature known as application initialization which allows you to present static content (ex.: an HTML page) while the application is completing its initialization tasks. In other words, with IIS 8, you can set an HTML page which is returned to the user while the application is “warming up”.

To use this feature in IIS 8, we need to make sure that the Application Initialization option is installed.

After insuring that, we need to configure the site’s application pool so that it gets started before IIS receives the first request for that site. In order to do that, we can fire up the application pool’s advanced property dialog and change its start mode property so that the AlwaysRunning option is set.

Now, we need to update the site’s preload behavior by changing the value of its Preload enabled property to true:

Now that the warming up is set up, we can still take this a little further and specify some static content which will be shown to the unlucky user that hits the site before it ends up its initialization tasks. To do that, we need to add the applitationInitialization element to the system.web section:

<applicationInitialization remapManagedRequestsTo="warmingup.html" skipManagedModules="true">
<add initializationPage="/default.aspx" />
</applicationInitialization>

With the previous entry, we’re saying that while the application is being initialized, IIS should return the contents of the warmingup.html file back to any client that tries to access the site. If the user sees this static page, he’ll be redirected to the default.aspx page when the warm up ends.  Notice that we can only serve static content during this phase (you can’t return an ASP.NET page because the app is still being initialized!).

And that’s it for now. Stay tuned for more.

In these last days, we’ve finished moving an existing web site to a new server which was running IIS 7.5. This site had an upload service which used streaming for allowing the upload of some interestingly sized files. We’ve already had it running without any problems in IIS 6 and 7 (though in this case, we tested it using Windows 7), so it was a surprise to see that nobody could make an upload after the migration. The streaming service was returning the 413.Request Entity Too Large.

After some digging, I’ve managed to find a discussion in the IIS Forums which suggested that the problem was related with the uploadReadAheadSize attribute of the serverRuntime element. And sure enough, changing its default value in the apphost config file solved this problem because we were using SSL and that means the request entity body must be preloaded (and when that happens, the SSL preload will use that value for doing its thing).

After a bad week (where my work machine died), I’ve finished reinstalling everything. This time, I’ve went with Windows 7 and as a bonus, I’ve ended up with IIS 7.5. One of the things I needed to recover my working environment was to configure access to the certificates’ private keys (I have several WCF services which need certificates). In the old days, the solution was to use the httpcertcfg tool and use the command line.

With IIS 7.5 (also available for IIS running in Vista and Server 2008 with SP2), we’ve got a “new” security feature called application pool identities. According to the docs, application pool identities “allow you to run app pools under a unique account without having to create and manage domains or local accounts”. Until now, everything looks good and this is, indeed, an welcomed new feature. Now, my problem was granting access to the private keys of the certificate to that account. Initially, I’ve tried using my beloved winhttpcertcfg tool:

C:Windowssystem32>winhttpcertcfg -g -c LOCAL_MACHINEMy -s mycertificate -a "IIS APPPOOLASP.NET v4.0"

The result: “Error: no account information found.” Not good. I know that I could use the good old FindPrivateKey utility,but I’ve thought that there should be an easy way of doing these things. And yes,there is. I’ve tripped into an even easier way of granting permissions to a private key (interestingly, available since Windows Vista – note to self: start poking around everywhere when new versions of an OS is released!).  Take a look at the following image:

Notice the Manage private keys entry? Yep, that’s just what the doctor ordered! Clicking over that option ends up showing the security dialog and now it’s only a question of adding the correct account (which, if you’re using the new application pool identity, is as easy as writing “IIS apppoolyour pool name”). Cool, right?