Configuration a web application for Application Warmup in IIS

Further to one of my previous blog posts about how to configure an ASP.NET web application for Application Initialization (warmup), here's the follow up: a powershell script for configuring the corresponding IIS application for warmup:


<# .SYNOPSIS Sets the required settings in the applicationHost.config file for an application to be able to automatically initialize. .PARAMETER WebSitePath The name of the web application that's to have it's settings configured for application warmup. .PARAMETER RestartService A switch to indicate that the W3SVC (IIS) service should be restarted after the change. #> function Set-WebApplicationInitialization { [CmdletBinding(SupportsShouldProcess = $true)] Param( [Parameter(Mandatory = $true)][ValidateNotNullOrEmpty()][string] $WebSitePath, [Parameter(Mandatory = $false)][switch] $RestartService ) $pathElements = $WebSitePath.Split('/') $site = $pathElements[0] $appSubPath = @($pathElements | select -Skip 1) -join '/' $webApp = Get-WebApplication -Site $site -Name $appSubPath if ($webApp -eq $null) { throw "Failed to find application '$appSubPath' under web site '$site'" } if ($PSCmdlet.ShouldProcess($WebSitePath, "Update application to use Application Initialization settings")) { $appPoolPath = "IIS:\AppPools\$($webApp.applicationPool)" Set-ItemProperty -Path $appPoolPath -Name 'autoStart' -Value 'true' Set-ItemProperty -Path $appPoolPath -Name 'startMode' -Value 'AlwaysRunning' Set-ItemProperty -Path $appPoolPath -Name 'processModel.idleTimeout' -Value '00:00:00' $applicationPath = "IIS:\Sites\$($WebSitePath)" Set-ItemProperty -Path $applicationPath -Name 'preloadEnabled' -Value $true Write-Verbose "Updated properties for web application '$appSubPath' running on pool '$($webApp.applicationPool)'" if ($RestartService.ToBool()) { if ($PSCmdlet.ShouldProcess("W3SVC", "Restart web service")) { Restart-Service W3SVC } } } }

My website doesn't accept my Active Directory credentials and just keeps prompting me over and over. Or if it's Chrome, just gives me a middle finger straight up.

Recently, I've been having the problem of trying to reach some of the internal applications that my company develops that uses Windows Authentication. Thanks to this article:

http://www.leftycoder.com/windows-authentication-chrome-iis/

... I found out why. I had to remove the option for 'Negotiate' with Windows Authentication. The settings had changed when we moved our applications to a new IIS Web Site. Something to keep in mind.

Bitten by IIS, or lack thereof

Here at the office, we build a number of web applications. I recently started refactoring one such application to change and improve how we deploy it. As soon as I made the change to the .csproj to remove some old configurations and add new ones, I mysteriously started getting this error on our build machine (and only our build machine):

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.targets (2664): Filename: redirection.configError: Cannot read configuration file

After examining the changes I made, I figured "there's nothing that should be causing this. WTF?" Then after a while, I went on to our build machine and found that we didn't actually have IIS installed on the build machines (which is a good idea from a security standpoint, because there's really no reason for a build machine to have IIS installed). So why did this start suddenly ?

I went and examined the exact line that was causing the problem in the targets file, and the only thing that appeared to be including this conditional statement was the flag 'IncludeIisSettings'. Sure enough, the old configuration which we never used before and were using now had this set.

A problem with redirect loops in IIS (8.5) with ASP.NET MVC 5 (and Identity)

Ever see something like this ?

http://localhost:80/MyApp/Account/Login?ReturnUrl=%2FMyApp%2FAccount%2FLogin%3FReturnUrl%3D%252FMyApp%252FAccount%252FLogin%253FReturnUrl%253D%25252FMyApp%25252FAccount%25252FLogin%25253FReturnUrl%25253D%2525252FMyApp%2525252FAccount%2525252FLogin%2525253FReturnUrl%2525253D%252525252FMyApp%252525252FAccount%252525252FLogin%252525253FReturnUrl%252525253D%25252525252FMyApp%25252525252FAccount%25252525252FLogin%25252525253FReturnUrl%25252525253D%2525252525252FMyApp%2525252525252FAccount%2525252525252FLogin%2525252525253FReturnUrl%2525252525253D%252525252525252FMyApp%252525252525252FAccount%252525252525252FLogin%252525252525253FReturnUrl%252525252525253D%25252525252525252FMyApp%25252525252525252FAccount%25252525252525252FLogin%25252525252525253FReturnUrl%25252525252525253D%2525252525252525252FMyApp%2525252525252525252FAccount%2525252525252525252FLogin%2525252525252525253FReturnUrl%2525252525252525253D%252525252525252525252FMyApp%252525252525252525252FAccount%252525252525252525252FLogin%252525252525252525253FReturnUrl%252525252525252525253D%25252525252525252525252FMyApp%25252525252525252525252FAccount%25252525252525252525252FLogin%25252525252525252525253FReturnUrl%25252525252525252525253D%2525252525252525252525252FMyApp%2525252525252525252525252FAccount%2525252525252525252525252FLogin%2525252525252525252525253FReturnUrl%2525252525252525252525253D%252525252525252525252525252FMyApp%252525252525252525252525252FAccount%252525252525252525252525252FLogin%252525252525252525252525253FReturnUrl%252525252525252525252525253D%25252525252525252525252525252FMyApp%25252525252525252525252525252FAccount%25252525252525252525252525252FLogin%25252525252525252525252525253FReturnUrl%25252525252525252525252525253D%2525252525252525252525252525252FMyApp%2525252525252525252525252525252FAccount%2525252525252525252525252525252FLogin%2525252525252525252525252525253FReturnUrl%2525252525252525252525252525253D%252525252525252525252525252525252FMyApp%252525252525252525252525252525252F

As it turns out, IIS can generate redirect loops whenever there's a freshly deployed (installed) MVC application that hasn't had its application pool correctly setup.

Just thought I'd put this here in case anybody else runs across it.

Using Ninject in an IIS-hosted environment to create a WCF service instance that's in a shared assembly (i.e. not the web application assembly)

Recently I wanted to create several WCF services for some of our internal applications and host these services in multiple different servers. There'd be no difference in the code between the locations where they'd be hosted. In order to avoid code duplication, I wanted to make these WCF services common and then just host them in the IIS applications. However, it's not as simple as creating a new (shared) assembly, creating the WCF service in that assembly and then sharing it between the different services. When I tried this, I ran into the problem where even though I specified the service in the config section:

<system.serviceModel>

         ....

</system.serviceModel> 

 

... it still wouldn't find my service and load it (I'm using Ninject as a dependency injection container for my WCF services).  They key to getting the shared services to be found and loaded properly was to create a .svc file in each of the services where the WCF services were shared, and it looked something like this in each case:

<%@ ServiceHost Language="C#" Debug="false" Service="MyWcfSharedServices.MySharedWebService" Factory="Ninject.Extensions.Wcf.NinjectServiceHostFactory" %>

After adding the .svc file and using the path to it in the system.serviceModel configuration in the configuration file, everything worked perfectly.

Journey to robust web services: Fixing an error 404.3 message in IIS 7.0 / 8.0

I've recently had to go out of town, and only had my personal laptop to take with me. I usually develop in a Windows 7 environment with IIS 7.0 / IIS Express 7.5, but my laptop is Windows 8, so of course I have to go through the process of setting up my development environment all over again. One of the common errors I see when setting up a new environment is error 404.3: Not found. I run into it over and over again and when I fix it, it seems like such a trivial thing and I never remember to write down the fix to reduce my setup time in the future. Today that changes. The problem can be caused by a couple of things:
1) You don't have the application setup in IIS. You need to setup the application in IIS, *and* you need to point it to your web project directory.
2) You don't have all the requisite components installed in IIS. In order to properly install WCF, you must have IIS installed, you must have ASP.NET installed, and you must have WCF registered. Up to Windows 7 / .NET 4.0, this means you must have, at some point, run aspnet_regiis.exe -ir. On Windows 8, this means you must have installed ASP.NET 3.5 / 4.5, and installed HTTP activation for each (as well as corresponding activations for any other protocols such as net.tcp.

Journey to robust Windows Services: Overriding the default web site when deploying your applications from the command line

I recently ran into a problem where I wanted to deploy a new application to the default web site on an old IIS 6 instance via MSDeploy on the command line from my build machine. Unfortunately, it decided to deploy the application in a folder immediately underneath the default web site, rather than as the default website itself. This post on the IIS forums provided the solution.

Journey to robust web services: installing a WCF 4.0 application on IIS 6.0

Due to budget and other constraints, I'm unable to get my hands on the latest and greatest software for running a WCF application I've been working on, so I'm forced to use what my company's got: Windows Server 2003 and IIS 6.0. Suffice it to say that working with these old bits of software are less than ideal. However, I'm stuck with it. So, moving forward, here's some of the things I found while working on the application:

1. There's no easy way to set certain items in the registry for the Network Service user. (Sorry, for various reasons, I can't elaborate on that statement.)
2. Due to (1), I've decided to run my application as a custom normal (non-Administrator) user that I've created. However in order to use this user with IIS and its applications, certain steps must be taken.

Using a custom user to run an IIS 6.0 application

The following are pre-requisites in order to be able to use a custom user to run an IIS 6.0 application:

• The user must have already been created and should have absolutely the least number of privileges possible.
• Thanks to this question on Stack Overflow, the following must also have the following:
• The "Log on as a service" right (Start -> Control Panel -> Administrative Tools -> Local Security Policy -> Local Policies -> User Rights Assignment -> Log on as a service)
• "Access this computer from the network" (similar location as in the step above)
• "Deny logon locally"
• "Log on as a batch job"
•  "Read & Execute", "List Folder Contents" and "Read" access to the file system that underpins the web site/application
• Thanks to this troubleshooting article on MSDN, I also found out that the user must be part of the "IIS_WPG" group.

I now have other problems to worry about with this application, but at least now I know that they're not related to how I'm running the application in IIS.