To demonstrate the capabilities of the tool, we will create a simple web farm that looks as on the following diagram:

• The load balancer will be using the Application Request Routing for IIS 7 and will also act as a Web Farm Controller. Web Farm Controller manages all the machines within the web farm and it has the Web Farm Framework 2.0 installed.
• The Primary Server, in addition to serving the web requests, also acts as an example server for all the other servers in the farm. Web Farm Framework will ensure that every new secondary server added to the web farm has exact same components installed and is configured exactly as the primary server.
• The Secondary Server(s) will serve web requests. It’s configuration and content matches the primary server.

Setting up a web farm

The example web farm will contain 3 servers:

1. DEMOCONTROLLER – this is the load balancer and controller machine. It has ARR 2.0 and Web Farm Framework 2.0 installed.
2. DEMOPRIMARY – this is the primary content server that has a PHP application setup. Here is what is installed on the primary server:
   
3. DEMOSECONDARY – this is the secondary content server that is a clean OS installation without any components or content installed. There is nothing installed on that server:
   

Once the Application Request Routing 2.0 and Web Farm Framework 2.0 have been setup on the controller server, the new web farm can be created by using IIS Manager UI:

In the “Add Server Farm” dialog specify the name for the web farm (e.g. demofarm) and make sure that “Server Farm is available for load balancing” and “Provision server farm” options are selected. You will also need to provide the credentials for the account that exists all all the web farm servers and that has administrative privileges on all those servers.

On next page add the primary server and the secondary server to it. The Web Farm Framework will verify that it can connect to those servers. If connection fails then most probably the firewall on a server is not configured correctly. Follow the instructions at System Requirements for the Web Farm Framework 2.0 to troubleshoot connection problems.

After both servers have been added, the Web Farm Framework starts provisioning the web farm. You can monitor the provision process by using the IIS Manager UI:

Here is what happens during the web farm provisioning:

1. The Web Farm Agent component is installed on both content servers in web farm. The Web Farm Agent is used to establish communication between each content server and the controller.
2. The primary server is added to the Web Farm and Web Deployment Tool is installed on it. Web Deployment Tool is used to synchronize the web content and configuration across all servers in the web farm.
3. The primary server is queried for all the installed components and for the web content.
4. The secondary server is added to web farm and the Web Deployment Tool is installed there too. After that all the same components that were installed on the primary server are also installed on the secondary server.
5. Finally both servers are marked as ready for load balancing, which means that they are now included in the web farm and web request will be routed to them.
   

After both servers have been added to the web farm, the secondary server has exact same components installed and exact same web content as the primary server:

The Web Farm Framework periodically checks all the servers to ensure that they are synchronized with the primary server. If any new component is installed on the primary server or if any content has been changed on the primary server, those changes will be propagated to secondary servers. As soon as another secondary server is added to the web farm, the provisioning process for that server will start automatically. This makes it very easy to add new servers to the web farm. Also, the servers in the web farm do not have to use exact same version of the operating system. For example a web farm can contain a mix of x86 and x64 machines, as well as Windows Server 2008 and 2008 R2.

More information

Automatic provisioning of the servers and applications in a web farm is one of the many capabilities of the Web Farm Framework. Other cool things included in Web Farm Framework are:

• Support for running server operations on the web farm nodes, e.g. starting and stopping services, rebooting and so on;
• API’s for managing web farms;
• PowerShell cmdlets for managing web farms.

More information about the Web Farm Framework 2.0 can be found at Microsoft Web Farm Framework 2.0 Beta for IIS 7.

This post has been updated from its original version to correct the installation instructions, which have changed since the time the post was written in Feb 2009.

With the addition of .NET Framework to Server Core in Windows Server 2008 R2 the Server Core installation option became even more appealing for those who want to use a very low footprint server for hosting their applications. Availability of .NET framework provides the following great benefits:

1. ASP.NET support – you can now use Server Core to host your ASP.NET applications.
2. IIS Remote Management – Server Core does not provide any user interface other than command line. But if you prefer to use IIS Manager UI to administer IIS, you can now use IIS Remote Manager to connect to IIS on Server Core and perform all the management tasks from within familiar UI of IIS Manager.
3. PowerShell – Windows Server 2008 R2 includes IIS PowerShell snapin, which is also available on Server Core.

This post describes how to setup and configure IIS on Server Core in Windows Server 2008 R2. Specifically the following tasks are described:

• Using oclist and ocsetup commands
• Basic Installation of IIS
• Installing ASP.NET
• Installing PowerShell and IIS snap-in
• Enabling IIS Remote Management

Using oclist and ocsetup commands

oclist command can be used to list the available and installed roles and services on the server. The output of the command looks similar to below:

It is important to understand how oclist renders component dependencies. For example, in the above screenshot the oclist output shows that IIS-FTPExtensibility is dependent on IIS-FTPSvc, so in order to install IIS-FTPExtensibility it is first necessary to install IIS-FTPSvc.

ocsetup command can be used to install and uninstall individual roles and services.

Basic Installation of IIS

To perform basic and default installation of IIS on Server Core run the following command:

start /w ocsetup IIS-WebServerRole

After the command has run you can run oclist | more and check which IIS components have been installed.

Installing .NET Framework

If you plan to use ASP.NET or IIS Remote Management then it is necessary to install .NET Framework first. To install it use the following commands:

start /w ocsetup NetFx2-ServerCore
start /w ocsetup NetFx2-ServerCore-WOW64

Installing ASP.NET

To install ASP.NET on Server Core run the following commands in exact same order as listed below:

start /w ocsetup WAS-NetFxEnvironment
start /w ocsetup IIS-ISAPIExtensions
start /w ocsetup IIS-ISAPIFilter
start /w ocsetup IIS-NetFxExtensibility
start /w ocsetup IIS-ASPNET

Installing PowerShell and IIS snap-in

First, install the PowerShell by running the command as below:

start /w ocsetup MicrosoftWindowsPowerShell

Next, launch the PowerShell by running this command:

\windows\system32\WindowsPowerShell\v1.0\powershell.exe

After running this command you should see a PowerShell prompt.

In order to enable the IIS snapin it is necessary to change the script execution policy by running this command:

Set-ExecutionPolicy RemoteSigned

Restart PowerShell for the policy changes to take effect. After re-entering the PowerShell import the IIS snapin:

import-module WebAdministration

After that you can get the list of available IIS cmdlets by typing

get-command –module WebAdministration

Refer to the article Managing IIS with IIS 7.0 PowerShell Snap-in for more information.

Enabling IIS Remote Management

In order to install IIS remote management service it is necessary to install .NET Framework first. Refer to the Installing .NET Framework section above for more details.

Install the IIS management service by executing this command:

start /w ocsetup IIS-ManagementService

Then enable remote management by running this command:

reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebManagement\Server ^
/v EnableRemoteManagement /t REG_DWORD /d 1

And finally start the management service:

net start wmsvc

Now you can connect to the IIS on the Server Core from a remote machine by using IIS Remote Manager.

Acknowledgement: thanks to Saad Ladki and Thomas Deml from IIS team for explaining to me all these steps.

Install the Dynamic IP Restrictions Beta Today!

Microsoft Dynamic IP Restrictions for IIS 7.0 – Beta (x86)

Microsoft Dynamic IP Restrictions for IIS 7.0 – Beta (x64)

If IIS already has IPv4 Address and IP restrictions module enabled then Dynamic IP Restrictions installer will need to un-install the existing module in order to continue the setup process. Note that the existing IPv4 configuration will be preserved while old module is removed and new module is installed.

Features

The Dynamic IP Restrictions includes these key features:

• Blocking of IP addresses based on number of concurrent requests – If HTTP client makes many concurrent requests then that client’s IP address gets temporarily blocked.
• Blocking of IP addresses based on number of requests over a period of time – If HTTP client makes many requests over short period of time then that client’s IP address gets temporarily blocked.
• Various deny actions – it is possible to specify what response to return to an HTTP client whose IP address is blocked. The module can return status codes 403 and 404 or just drop the HTTP connection and do not return any response.
• Logging of dynamically denied requests – all denied requests can be logged into a W3C formatted log file.
• Displaying currently blocked IP addresses – a list of currently blocked IP addresses can be obtained by using IIS Manager or by using IIS RSCA API’s.
• IPv6 – the module fully supports IPv6 addresses.

In additions to these features, the Dynamic IP Restrictions for IIS 7.0 provides the same functionality that exists in IIS 7.0 built-in IPv4 and Domain Restrictions. Because of that the Dynamic IP Restrictions is provided as a replacement for IPv4 and Domain Restrictions.

More information

Module walkthrough: http://learn.iis.net/page.aspx/548/using-dynamic-ip-restrictions/

Support forum: http://forums.iis.net/1043.aspx

Let me demonstrate this on an example. Assume you have a very simple web form in a file called default.aspx. When you request http://localhost/default.aspx in a browser and then view the HTML source for the response, you will see that the response contains the <form> element, which looks similar to this:

<form name="form1" method="post" action="Default.aspx" id="form1">

The action attribute contains the URL where the form data will be posted to when you click on the button in the web page.

Now, let’s create a very simple rewrite rule that rewrites URL from http://localhost/homepage to http://localhost/default.aspx.

<rewrite>
  <rules>
    <rule name="MyRule" patternSyntax="Wildcard">
      <match url="homepage" />
      <action type="Rewrite" url="default.aspx" />
    </rule>
  </rules>
</rewrite>

When you request http://localhost/homepage in a browser, the URL will be rewritten in accordance to the above rule and the page will be shown correctly in the browser:

However, when you click on the Submit button, the browser’s address bar will display http://localhost/default.aspx, thus exposing the internal URL, that you wanted to hide by using URL rewriting:

A few workarounds to fix this behavior existed in previous versions of ASP.NET. For example, you could sub-class the form control, or use Control Adapter as explained here.  However, these workarounds were not very easy to implement. Luckily, the ASP.NET in .NET Framework 3.5 SP1 provides a very simple way to fix that. Now you can use the property of the HtmlForm class called Action to set the postback URL to the one that was requested by browser before any rewriting happened. In ASP.NET you can obtain that URL by using HttpRequest.RawUrl property. So, to fix the postback URL for your web form when you use URL Rewrite Module, you would need to add the following code to the page:

protected void Page_Load(object sender, EventArgs e)
{
    form1.Action = Request.RawUrl;
}

After this change, if you reload the web page at http://localhost/homepage and then click on submit button you will see that the browser’s address bar still displays the correct URL:

If you view the HTML for the response you will see that the <form> tag now contains the correct action URL:

<form name="form1" method="post" action="/homepage" id="form1">

When you use ASP.NET master pages you could add the Page_Load method to the master page and that would take care of postback action URL for all the pages in your web application. Note thought that in order to be able to use the HtmlForm.Action property you have to upgrade to .NET Framework 3.5 SP1.

IIS 6 did not have this level of integration. ASP.NET was plugged into IIS 6 as an ISAPI extension and by default was configured to handle ONLY requests mapped to that extension – for example any request that ended with “.aspx” would be be processed by ASP.NET extension. This obviously was a big limitation for customers who wanted to be able to use ASP.NET features for all other contend on web site. The most common way to workaround that was to use “Wildcard script mapping”. This post explains how an application that used wildcard script mapping in IIS 6 can be migrated over to IIS 7.

Assume you had configured ASP.NET in IIS 6 to handle all requests by using wildcard script mapping. For example you had an ASP.NET module for URL rewriting and you wanted this module to handle extension-less URLs.

This wildcard script map configuration is typically done within IIS 6 manager by opening the properties dialog for either web server or web site and selecting Home Directory tab, then clicking on Configuration button and then clicking on the Insert button for “Wildcard application maps”:

Now, as you move your application to IIS 7, you want to configure it to achieve the same behavior of ASP.NET. There are two options on how this can be done: using Classic pipeline mode or using Integrated pipeline mode.

Wildcard script mapping in IIS 7 classic pipeline mode

With classic pipeline mode the ASP.NET is plugged into the IIS request processing pipeline as an ISAPI extension – exactly the same way as it was in IIS 6. In fact, if you open %WINDIR%\system32\inetsrv\config\applicationHost.config file and locate the <handlers> section inside of it you can see how IIS is configured to map ASP.NET specific requests to the aspnet_isapi.dll:

<handlers accessPolicy="Read, Script">
  ...
  <add name="PageHandlerFactory-ISAPI-2.0"
       path="*.aspx" verb="GET,HEAD,POST,DEBUG"
       modules="IsapiModule"
       scriptProcessor="%windir%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll"
       preCondition="classicMode,runtimeVersionv2.0,bitness32" responseBufferLimit="0" />
  ...
</handlers>

Notice the preCondition attribute for the handler mapping. Among other things this attribute is set to classicMode, which ensures that this handler mapping only takes effect when the application pool is configured to run in classic mode.

Now if you want to configure wildcard mapping for the ASP.NET running in classic mode, you can add one more handler mapping to the <handlers> section just before the handler mapping for static files:

<handlers accessPolicy="Read, Script">
  ...
  <add name="ASP.NET-ISAPI-2.0-Wildcard"
     path="*" verb="GET,HEAD,POST,DEBUG"
     modules="IsapiModule"
     scriptProcessor="%windir%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll"
     preCondition="classicMode,runtimeVersionv2.0,bitness32" responseBufferLimit="0" />
  <add name="StaticFile"
     path="*" verb="*"
     modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule"
     resourceType="Either" requireAccess="Read" />
</handlers>

The relative order of the wildcard handler mapping is important: if you define this handler mapping after the “StaticFile” handler mapping then “StaticFile” will handle all the requests and no requests will ever come to ASP.NET wildcard handler.

As you may already know the ASP.NET wildcard handler mapping in IIS 7 is subject to the same performance limitations as existed in IIS 6. The problem with this kind of handler mapping is that ALL requests are processed by it, including requests for static files. The ASP.NET static file handler is not as powerful as native IIS static file handler. Plus static files served by ASP.NET will not be cached by IIS in kernel mode. Because of these performance limitations it is recommended that you use IIS 7 integrated pipeline to achieve the same functionality as with wildcard mappings in IIS 6.

IIS 7 integrated pipeline instead of wildcard script mapping

With integrated pipeline, the ASP.NET functionality is fully integrated into the main request processing in IIS, which means that all ASP.NET features are now available for any type of requests. This effectively eliminates the need for the wildcard handler mapping. Now you can use your existing ASP.NET modules and have them applied to all requests.

For example let’s say you had a URL rewriting module written in ASP.NET. On IIS 6 this module was registered inside of the <system.web> section in web.config file as below:

<system.Web>
  <httpModules>
    ...
    <add name="MyUrlRewrite"
         type="SomeNamespace.MyModules.UrlRewrite, SomeNamespace.MyModules" />
    ...
  </httpModules>
</system.Web>

Since on IIS 6 this module was only executed for requests to managed content, it only worked for URLs that had .aspx extension, such as http://example.com/archive/2008/08/26/post-title.aspx. If you wanted it to handle extension-less URLs you had to configure wildcard script mapping for ASP.NET. With IIS 7 integrated pipeline you do not have to do that anymore. In order to make this module apply to extension-less URLs you need to register it within the <system.webServer> section inside of web.config file as below:

<system.webServer>
  <modules >
    ...
    <add name="MyUrlRewrite"
         type="SomeNamespace.MyModules.UrlRewrite, SomeNamespace.MyModules"
         preCondition="" />
    ...
  </modules>
<system.webServer>

Make sure that you leave the preCondition attribute empty here as it would enforce that the module will be executed for all requests, not just for requests for ASP.NET specific content.

Registering your managed modules this way does not have such dramatic performance impact as when using wildcard script mappings. Even though the module is invoked for all requests to web application, all the existing handler mappings are still in effect, which means that the static files are still served by the native IIS static file handler. Another benefit of registering your module this way is that now it can be applied to requests for PHP, ASP or any other dynamic pages. You would not be able to do that if you used wildcard script mappings.

One last thing to mention here is that you can also use the attribute on the <modules> section called runAllManagedModulesForAllRequests.

<system.webServer>
  <modules runAllManagedModulesForAllRequests="True" >
    ...
    <add name="MyUrlRewrite"
         type="SomeNamespace.MyModules.UrlRewrite, SomeNamespace.MyModules"
         preCondition="ManagedHandler" />
    ...
  </modules>
<system.webServer>

This attributes forces IIS to ignore the preCondition=”managedHandler” attribute, hence all managed modules will be invoked for all requests to web application.

Being a technical program manager on the team, I like to use (in other words – “dogfood”) the products that team develops. Hence I decided to self-host my own blog by using latest version of IIS. Also, I have been working with FastCGI and PHP for a while now, and became quite familiar with many popular PHP applications. As a result I chose to run my blog by using latest version of WordPress, which is a very nice and easy to use blog engine application. Finally, I am using my favorite feature of IIS 7.0 – URL rewriter – to enable “pretty permalinks” on my blog.

I plan to use this blog to publish information related to FastCGI, PHP, URL rewriter and IIS in general. I hope you’ll find this content useful.