Windows 2008r2 is good in so many ways, I can never list them all. Of course, being the server variant of Windows 7, it means you can use all the nice interface enhancements that are also available in Windows 7.

Both Windows 7 and Windows 2008r2 have IIS 7.5 on board. One of the most interesting enhancements in IIS 7.5 is something called the Application Pool Identity (AppPoolIdentity). In Windows 2008r2 this is the default setting for new application pools. With this setting, IIS can create a unique virtual windows account, using the name of the application pool. Accounts created like this have the same networking capabilities as the well known NETWORKSERVICE account, however, because they are unique, they can also be used to secure physical files in your system.

So, lets see how we can use this to quickly install DotNetNuke in a secure manner.

The zeroth step in this installation is creating the database, which i am not going to write out completely. It should suffice to say that we have created a new database in SQL server, and a new SQL server login, and gave that login DBO rights on the newly created database.

So lets begin by downloading and unzipping the latest stable DNN version (5.4.4. at the time of writing). By the way, we are using the excellent zip application 7zip for everyting zip related. More about that in another blog. In this case we are using DotNetNuke 5.4.4, the install package.

Next step is to modify the file web.config. Most imporantly, the database connection string needs to be modified, so the application will know where and how to find the database. Of course, be sure to change both connectionstrings, since there are still modules arround that use the legacy connection string. My connection string looks like this:

<add name="SiteSqlServer" connectionString="Server=***;Database=***;uid=***;pwd=***;" providerName="System.Data.SqlClient" />

There are 2 settings in web.config that I often change as well: AutoUpgrade and UseInstallWizard. Setting the first to false ensures that the site installation does not start by accident (either by me or by another visitor), the latter makes it a bit faster: I  always use the auto install feature of the installation wizard anyway, and setting UseInstallWizard to false ensure that installation starts right away when I trigger it.

Next up is creating the site in IIS (the actual topic of this post). We came up with an IIS website naming scheme that matches the physical location of the site: [clientname]_[application number for this client]_[application name], eg: 40fingers_01_latest, which matches the physical location drive:\websites\40fingers\01\latest. Also, the name of the application pool the site is running in will be the same as the website name. When there are multiple people involved in administering a server, this will make it a lot easier to keep track about what is going on. Anyway, the settings I am using to create this new DNN application are:

• site name: 40fingers_01_latest
• application pool: automatic creation
• physical path: drive:\websites\40fingers\01\latest
• hostname: latest.stage.40fingers.net

We now have an application pool named 40fingers_01_latest. Now we need to set the security properties for the application directory. We are going to give full access to the automatically created virtual account. The name of this account in this case is iis apppool\40fingers_01_latest. Also, we will give access to the builtin IUSR account (read only access). The security properties will look something like this:

We now can surf to our website and start the DotNetNuke installation process. Because we set both AutoUpgrade and UseInstallWizard to false in the webconfig, DNN automatically redirects to the "under construction", in our case this is http://latest.stage.40fingers.net/Install/UnderConstruction.htm. From this url we can "easily" start the installation process, just browse to http://latest.stage.40fingers.net/Install/install.aspx?mode=install. This URL will tricker the auto install, and DotNetNuke will install with all the auto settings as they are set up in the installation configuration files.

When we switched over to Windows 2008r2, this new IIS feature was one of the gems to discover. Setting up secure hosting environments for clients is so much less work now than it used to be in Windows 2003.

More information about the Application Pool Identity can be found here