ASP.NET Integration with IIS 7

Introduction

Since its release, ASP.NET has been the platform of choice for developing Web applications on the Windows / IIS platform. ASP.NET 2.0 took Web application development to a new level, allowing developers to build more powerful applications faster than ever before.

IIS 7 takes ASP.NET further by integrating the ASP.NET runtime extensibility model with the core server. This allows developers to fully extend the IIS 7 server with the richness of ASP.NET 2.0 and the .NET Framework, instead of using the less capable IIS C++ APIs. Existing ASP.NET applications also immediately benefit from tighter integration by using existing ASP.NET features like Forms authentication, roles, and output caching for all content.

While IIS 7 provides the improved ASP.NET integration by default, there is a choice: IIS 7 supports both the new and the old ASP.NET integration modes that can be used side by side on the same server.

This article discusses the improvements that are introduced by the new ASP.NET integration mode, the architecture of the two modes, and describes how to select and configure the integration modes for ASP.NET applications.

ASP.NET Enhancements on IIS 7

Better ASP.NET integration in IIS 7 enhances existing applications and also allows new applications to take advantage of ASP.NET features in new ways:

• ASP.NET services can be used for all content types. In the past, ASP.NET functionality such as Forms authentication, roles, URL authorization, and output caching were only available to ASP.NET content types like ASPX pages. Static files, ASP pages, and other content types could not benefit from these services.

In IIS 7, all ASP.NET services are provided uniformly to all content. For example, you can protect all of your Web content, including images and ASP pages, with your existing ASP.NET 2.0 access control solution built on ASP.NET Forms authentication, membership and login controls.

• Fully extend IIS with ASP.NET. Previous versions of IIS frequently required server extensibility to be developed by using the native ISAPI filter or extension extensibility mode, due to the runtime limitations of ASP.NET.

IIS 7 allows ASP.NET modules to plug in directly into the server pipeline, with the same runtime fidelity as modules developed with the native (C++) server API. ASP.NET modules can execute in all runtime stages of the request-processing pipeline, and can be executed in any order with respect to native modules. The ASP.NET API is also expanded to allow more control over request processing than was previously possible.

• Unified server runtime. Tighter ASP.NET integration also unifies many of the features between IIS 7 and ASP.NET.

IIS 7 provides a unified configuration for IIS and ASP.NET modules and handlers. Many other features, including custom errors and tracing, have been unified to allow better management and cohesive application design.

ASP.NET Integration Architecture

In IIS 6.0 and previous releases, ASP.NET was implemented as an IIS ISAPI extension.

In these earlier releases, IIS processed a request to an ASP.NET content type and then forwarded that request to the ASP.NET ISAPI DLL, which hosted the ASP.NET request pipeline and page framework. Requests to non-ASP.NET content, such as ASP pages or static files, were processed by IIS or other ISAPI extensions and were not visible to ASP.NET.

The major limitation of this model was that services provided by ASP.NET modules and custom ASP.NET application code were not available to non-ASP.NET requests. In addition, ASP.NET modules were unable to affect certain parts of the IIS request processing that occurred before and after the ASP.NET execution path.

 Figure 1: IIS 6.0 & ASP.NET Pipelines

In IIS 7, the ASP.NET request-processing pipeline overlays the IIS pipeline directly, essentially providing a wrapper over it instead of plugging into it.

IIS 7 processes requests that arrive for any content type, with both native IIS modules and ASP.NET modules providing request processing in all stages. This enables services that are provided by ASP.NET modules, such as Forms authentication or output cache, to be used for requests to ASP pages, PHP pages, static files, and so on.

The ability to plug in directly into the server pipeline allows ASP.NET modules to replace, run before, or run after any IIS 7 functionality. This enables, for example, a custom ASP.NET Basic authentication module that is written to use the Membership service and SQL Server user database to replace the built-in IIS Basic authentication feature that works only with Windows accounts.

In addition, the expanded ASP.NET APIs use direct integration to enable more request-processing tasks. For example, ASP.NET modules can modify request headers before other components process the request, by inserting an Accept-Language header before ASP applications execute, which forces localized content to be sent back to the client based on user preference.

Figure 2: IIS 7 Integrated Mode

Because of the runtime integration, IIS 7 and ASP.NET can use the same configuration to enable and order server modules, and to configure handler mappings. Other unified functionality includes tracing, custom errors, and output caching.

Compatibility

Most notably, the architecture maintains the ASP.NET runtime architecture and APIs, which allows existing ASP.NET applications and services to work upon installation. With a few modifications, the existing ASP.NET applications and services can take advantage of the new ASP.NET capabilities.

Likewise, developers can continue to write new applications to familiar ASP.NET APIs while they harness the benefits of the runtime integration.

IIS 7 continues to provide the Classic ASP.NET mode for ASP.NET applications that have specific compatibility requirements that are not met by the Integrated mode. Administrators can select the desired integration mode per application pool, which lets applications that use both the new and the Classic ASP.NET modes to function side-by-side on the same server.

Migrating ASP.NET Applications to IIS 7 Integrated Mode

On IIS 7, ASP.NET is configured to operate in the new Integrated mode by default. This lets your application take advantage of Integrated mode enhancements with minimal modifications.

Because of the configuration unification, some applications may require migration to operate properly in Integrated mode. By default, the server provides assistance with migration. It detects applications that require migration, and returns an error message requesting that you migrate the application.

The following configuration causes the migration error:

1. The application Web.config file defines <httpModules> configuration.
   The application loads new ASP.NET modules or removes existing ones.
   In Integrated mode, ASP.NET modules are specified with native modules in the unified <system.webServer>/<modules> configuration section.
   The ASP.NET modules that are specified in the <system.web>/<httpModules> configuration section must be moved to the new configuration section to take effect. Subsequently, new ASP.NET modules must be added directly to the unified <modules> section.
2. The application Web.config file defines <httpHandlers> configuration.
   The application uses custom handler mappings for some content types.
   In Integrated mode, ASP.NET handler mappings must be specified in the unified <system.webServer>/<handlers> configuration section to take effect. Subsequently, new ASP.NET handler mappings must be added directly to the unified <handlers> section.
   This section replaces both the ASP.NET <httpHandlers> configuration and the IIS 7 scriptmaps configuration, both of which previously had to be configured to set up an ASP.NET handler mapping.
3. The application Web.config file defines <identity impersonate="true" /> configuration.
   The application impersonates client credentials, which is most common with intranet applications. In Integrated mode, client impersonation is not available in some early request-processing stages. In the majority of cases, this is not a problem and you can turn off the migration error. Otherwise, you must configure this application to run by using the Classic ASP.NET mode.

When the migration error is generated, it can generally either migrate the application configuration (recommended in cases 1 and 2, above), or move the application to use Classic ASP.NET mode (in case 3).

Migrating the Application Configuration

IIS 7 migrates the application by using the AppCmd.exe command line tool to perform the migration. The migration error message contains the command that is executed in the command line window, which you must run with administrator user rights, to instantly migrate your application to Integrated mode.

The basic format of the migration command is as follows:

%windir%\system32\inetsrv\APPCMD.EXE migrate config <Application Path>

Where <Application Path> is the virtual path of the application that contains the site name, such as "Default Web Site/app1".

When the migration is complete, your application will run in both Integrated and Classic modes without any problems.

Note: If you change the configuration after migration, the server will not prompt you to migrate again. After the initial migration, you must make sure that your configuration remains in sync between the two modes. You can manually migrate the application again by using the AppCmd.exe command line tool.

Moving Back to Classic ASP.NET Integration Mode

If you would rather return to the Classic ASP.NET mode, move your application to an application pool that is configured to run in Classic mode. Other applications continue to run in the new Integrated mode side-by-side with the Classic mode application.

For more information about how to move an application to the Classic ASP.NET mode, see Changing ASP.NET Modes for an Application.

Disabling the Migration Error Message

If you have manually migrated your configuration or want to remain in Integrated mode without migrating your configuration (not recommended), you can disable the migration error message by adding the following to the application's Web.config file:

<system.webServer>
<validation validateIntegratedModeConfiguration="false" /> 
</system.webServer>

Note: The server automatically disables the error message after migrating the configuration with the AppCmd.exe command line tool.

If you manually disable the migration error message, you must make sure that your application works properly in Integrated mode, because the server will no longer provide any warnings about the unsupported configuration.

Changing ASP.NET Modes for an Application

If your application does not work properly in Integrated ASP.NET mode, you can move it to the Classic ASP.NET mode by moving it to another application pool. Each application pool is individually configured to use the desired ASP.NET integration mode. This lets you run groups of applications that use different ASP.NET integration modes side-by-side on the same server.

To change the ASP.NET integration mode for an application:

1. Find or create an application pool that is configured to use the desired mode.
   By default, all new application pools run in Integrated mode.
   The ASP.NET set up provides an application pool named "Classic .NET AppPool" that runs in the classic ASP.NET integration mode. You can use this application pool for applications that should not run in Integrated mode.
   You can also change the ASP.NET mode of the existing application pool by using the IIS 7 Administration Tool or the AppCmd.exe command line tool, or by manually editing the application pool configuration.
2. Set the application to use that application pool.
   Each application is configured to use a particular application pool. By default, all applications use the default application pool named "DefaultAppPool", which runs in Integrated mode.
   You can change the application pool of an application by using the IIS 7 Administration Tool or the AppCmd.exe command line tool, or by manually editing the application configuration.

Selecting an ASP.NET Version for an Application

Historically, IIS has supported multiple versions of ASP.NET / CLR side-by-side. For example, IIS allows the same server to run ASP.NET applications by using .NET Framework v1.1 and v2.0. This support was provided by mapping a corresponding version of ASPNET_isapi.dll to serve requests for the ASP.NET content by using the IIS 7 scriptmaps configuration.

For example, you can use the following scriptmap configuration to enable side-by-side support:

1. ASP.NET v1.1 application on /app1:
   *.aspx -> d:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll
2. ASP.NET v2.0 application on /app2:
   *.aspx -> d:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll

When the application receives a *.aspx request, IIS 7 loads the specified aspnet_isapi.dll, which loads the correct CLR version into the worker process, and processes the request.

ASP.NET also provides the following ways to configure side-by-side scriptmaps:

1. ASP.NET MMC extension. When you pick the version of ASP.NET to use, the extension automatically configures the scriptmaps for the application to point to the correct version of aspnet_isapi.dll.
2. ASP.NET aspnet_regiis.exe. Use the –i and –r options to install the scriptmaps that point to the corresponding ASP.NET version.

Unfortunately, due to the limitation of the ability to load only one CLR version into a single worker process, you must make sure that two applications that use different versions of ASP.NET are never configured to exist within the same application pool. When this common mistake is made, the first request loads the CLR of the corresponding aspnet_isapi.dll, and subsequent requests to the other version within the same application pool will fail.

IIS 7 recognizes that the application pool is the ASP.NET version that you select to run an application under. As such, the version of the CLR / ASP.NET that is loaded in the application pool is explicitly configured in the application pool configuration. By default, IIS 7 pre-loads the CLR that is specified by this setting when loading the worker process (unless the version is configured to be empty).

Because application pools are the .NET Framework versioning boundary, you can change the version of an ASP.NET application by doing the following:

1. Move the application to an application pool that uses the desired ASP.NET version.
   By default, applications use the default application pool named "DefaultAppPool," which runs ASP.NET v2.1 in Integrated mode. Move the application to the "Classic .NET AppPool" to run in ASP.NET v2.1 Classic mode, or another application pool of your choice.
2. Configure the application pool within which the application is running to use the desired ASP.NET version.
   By default, all new application pools are configured to run ASP.NET v2.1 in Integrated mode.

Note: Do not use aspnet_regiis /i or /r options to configure the version of ASP.NET for a particular application, or globally.

IIS 7 uses pre-conditioned handler mappings to automatically select the correct set of handler mappings (to ASPNET_isapi.dll in Classic mode or directly to managed handler types in Integrated mode) depending on the configured CLR version and managed integration mode of the application pool. The ASP.NET 2.0 setup installs these handler mappings at the server level.

Taking Advantage of Integrated ASP.NET Mode

On IIS 7, ASP.NET applications run in Integrated mode by default. However, to take advantage of the benefits that are provided by tighter integration, you must make some modifications to the application configuration. You can also develop new ASP.NET components that take advantage of the Integrated mode to provide powerful functionality to your application.

Enabling ASP.NET Services for All Types of Content

In Integrated mode, services that are provided by ASP.NET modules are available to requests for all content types. However, by default, ASP.NET modules are configured to execute only for requests to ASP.NET content for backward compatibility.

To do this, attach a managedHandler precondition to each ASP.NET module in the configuration section at the server level:

<modules>
     <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule"
             preCondition="managedHandler" />
     <add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule"
             preCondition="managedHandler" />
    ...
</modules>

The precondition is a rule that the server evaluates on every request to determine whether a module will be executed. The managedHandler precondition is only true for requests to content types that are mapped to ASP.NET handlers.

To apply functionality that is provided by an ASP.NET module to all requests, remove the module entry, and then re-add it without the precondition in the application's root Web.config file.

To enable ASP.NET Forms authentication for the entire application, modify your Web.config file as follows:

<modules>
    <remove name="FormsAuthentication" />
     <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" />
    …
</modules>

With this change, the FormsAuthentication module executes for all requests in your application. This lets you protect all of the application content with Forms authentication.

You can also use a shortcut to enable all managed (ASP.NET) modules to run for all requests in your application, regardless of the "managedHandler" precondition. To enable all managed modules to run for all requests without configuring each module entry to remove the "managedHandler" precondition, use the runAllManagedModulesForAllRequests property in the <modules> section:

<modules runAllManagedModulesForAllRequests="true" /> 

When you use this, the "managedHandler" precondition has no effect and all managed modules will run for all requests.

Experiment with enabling other ASP.NET modules to apply to your entire application. For example, use the ASP.NET Output Cache module to output cache ASP pages, or use URL Authorization and Role Manager to configure access control rules for your photos. Or, develop your own module to bring the power of ASP.NET to your entire Web site.

Building More Powerful ASP.NET Services

In Integrated mode, ASP.NET modules apply their services to all content. In addition, because ASP.NET modules execute in the unified request-processing pipeline in Integrated mode, they subscribe to the same request-processing stages and perform the same tasks as native server modules. At the same time, ASP.NET APIs remain largely the same, with a few key additions that unlock previously unavailable functionality.

Runtime Fidelity

In Integrated mode, the ASP.NET request-processing stages that are exposed to modules are directly connected to the corresponding stages of the IIS 7 pipeline. The complete pipeline contains the following stages, which are exposed as HttpApplication events in ASP.NET:

1. BeginRequest. The request processing starts.
2. AuthenticateRequest. The request is authenticated. IIS 7 and ASP.NET authentication modules subscribe to this stage to perform authentication.
3. PostAuthenticateRequest.
4. AuthorizeRequest. The request is authorized. IIS 7 and ASP.NET authorization modules check whether the authenticated user has access to the resource requested.
5. PostAuthorizeRequest.
6. ResolveRequestCache. Cache modules check whether the response to this request exists in the cache, and return it instead of proceeding with the rest of the execution path. Both ASP.NET Output Cache and IIS 7 Output Cache features execute.
7. PostResolveRequestCache.
8. MapRequestHandler. This stage is internal in ASP.NET and is used to determine the request handler.
9. PostMapRequestHandler.
10. AcquireRequestState. The state necessary for the request execution is retrieved. ASP.NET Session State and Profile modules obtain their data.
11. PostAcquireRequestState.
12. PreExecuteRequestHandler. Any tasks before the execution of the handler are performed.
13. ExecuteRequestHandler. The request handler executes. ASPX pages, ASP pages, CGI programs, and static files are served.
14. PostExecuteRequestHandler
15. ReleaseRequestState. The request state changes are saved, and the state is cleaned up here. ASP.NET Session State and Profile modules use this stage for cleanup.
16. PostReleaseRequestState.
17. UpdateRequestCache. The response is stored in the cache for future use. The ASP.NET Output Cache and IIS 7 Output Cache modules execute to save the response to their caches.
18. PostUpdateRequestCache.
19. LogRequest. This stage logs the results of the request, and is guaranteed to execute even if errors occur.
20. PostLogRequest.
21. EndRequest. This stage performs any final request cleanup, and is guaranteed to execute even if errors occur.

By using the familiar ASP.NET APIs, the ability to execute in the same stages as IIS 7 modules makes tasks that were only previously accessible in native ISAPI filters and extensions now possible in managed code.

 For example, you can now write modules that do the following:

1. Intercept the request before any processing has taken place, for example rewriting URLs or performing security filtering.
2. Replace built-in authentication modes.
3. Modify the incoming request contents, such as request headers.
4. Filter outgoing responses for all content types.

Expanded ASP.NET APIs

The ASP.NET APIs remain backward compatible with previous releases, which allows existing modules to work in IIS 7 without modification, and to apply to all application content without code changes.

However, modules that are written for IIS 7 Integrated mode can take advantage of a few additional APIs to enable key request-processing scenarios that were not previously available.

The new HttpResponse.Headers collection allows modules to inspect and manipulate response headers that other application components generate. For example, you can change the Content-Type header that is generated by an ASP page to prompt a download dialog box in the browser. The Cookies collection on the HttpResponse class is also enhanced to allow modification of cookies that are generated as part of the request processing, even if they were created outside of ASP.NET.

The HttpRequest.Headers collection is write-enabled, which allows modules to manipulate the incoming request headers. Use this to change the behavior of other server components – for example, you can force a localized application to respond to the client in a different language by dynamically changing the value of the Accept-Language header.

Finally, the HttpRequest.ServerVariables collection is now writeable, which allows IIS 7 server variables to be set. ASP.NET modules use this functionality to change values that are provided by IIS 7, and to create new server variables that are visible to other application frameworks, like PHP.

Runtime Integration

In addition to the new APIs, Integrated mode enables existing ASP.NET functionality to provide more value to your application.

The tracing facilities that are provided by ASP.NET, including the System.Diagnostics.Trace class and the ASP.NET page tracing feature, now emit trace information into the IIS 7 trace system. This enables the trace information that is generated during request processing by both IIS 7 and ASP.NET components to be placed in a single log file, facilitating better diagnostics of server issues.

The ASP.NET response-filtering feature, which allows responses to be changed by using a Stream interface before it goes to the client, is enhanced to allow filtering of non-ASP.NET content. Therefore, you can use ASP.NET filtering on all server content, or selectively install the filter only for requests to content that you want to process. With this capability, you can write filtering features that inject or censor certain content in the site's responses, regardless of whether this content comes from an ASPX page or a static file.

Summary

ASP.NET Integration in IIS 7 unlocks the full potential of ASP.NET, enabling developers to create powerful server components with the ease and richness of ASP.NET and the .NET Framework.

Install IIS SMTP for a Windows 2008 server

This article will explain how to install IIS SMTP for Windows 2008.

   1. Log into your server through Remote Desktop Connection
   2. Open Server Manager under Start > All Programs > Administrative Tools
   3. Click Features > Add Features

4. Check the checkbox for SMTP Server

5.A warning may pop up asking to install related software as part of the SMTP installation process. Click Add Require Features. Then click Next

6. Then click Install and the SMTP services within IIS 6 will be installed once completed

Once installed, navigate to Start > All Programs > Administrative Tools and open Internet Information Services (IIS) Manager 6. Drill down and you will see Default SMTP Server which is where the software can be configured.

Preview your site on a Windows Server with IIS 7 Host Headers

Let's make an example, say that your server IP address is 1.2.3.4 and your domain is mydomain.com. You are working on the site and want to test the site on your server at Hosting.com however you are not ready to update DNS just yet.

For this tutorial it is important to under host headers and how to set them inside of IIS

Modify Host Header Information in IIS7

1. Start > Run > inetmgr > Press Enter Key

2. Expand Sites

3. Right Click on Web Site to be Adjusted and Choose Edit Bindings

4. To Edit an Existing Highlight the Record and Click Edit or Click Add To Add a New Record

5.Select the Proper IP Address, TCP Port, and Host Header Value

6. Hit OK

Preview Your Site

If you are only hosting one site and this site is the only site bound to port 80 inside of IIS you can simply access the site using the server IP address at http://1.2.3.4

If you are hosting more than one site on a Windows server you'll need to configure individual host headers for each site as all site(s) must have a unique binding.

The simplest solution for previewing a site on a Windows server is by adjusting the host header information to use an alternate port. If you adjust the host header of your test site from 80 to 8080 you can then access your site at http://1.2.3.4:8080

Another option that allows you to preview a site before updating the DNS is by creating a sub-domain record to preview the site. You can create a DNS record of test as an A record pointing to the IP address of your server at Hosting.com therefore test.mydomain.com resolves to your server solution.

Then you'll need to configure your server to listen for requests for test.mydomain.com. Inside of IIS you'll need to create a host header of test.mydomain.com listening on IP 1.2.3.4 for traffic on port 80.

This will allow the http://test.mydomain.com to resolve to this site inside of IIS.

Configuring FTP and FTP Firewall Settings in IIS 7

Introduction

Microsoft has created a new FTP service that has been completely rewritten for Windows Server® 2008. This FTP service incorporates many new features that enable web authors to publish content better than before, and offers web administrators more security and deployment options.

Prerequisites

The following items are required to be installed to complete the procedures in this article:

1. IIS 7 must be installed on your Windows 2008 Server, and Internet Information Services (IIS) Manager must be installed.

2.You must create a root folder for FTP publishing:

• Create a folder at "%SystemDrive%\inetpub\ftproot"
• Set the permissions to allow anonymous access:
  • Open a command prompt.
  • Type the following command:
    ICACLS "%SystemDrive%\inetpub\ftproot" /Grant IUSR:R /T
• Close the command prompt.

Important Notes:

• The settings listed in this walkthrough specify "%SystemDrive%\inetpub\ftproot" as the path to your FTP site. You are not required to use this path; however, if you change the location for your site you will have to change the site-related paths that are used throughout this walkthrough.
• Once you have configured your firewall settings for the FTP service, you must configure your firewall software or hardware to allow connections through the firewall to your FTP server.
• If you are using a different firewall, please consult the documentation that was provided with your firewall software or hardware.

Use the FTP Site Wizard to Create an FTP Site With Anonymous Authentication

In this section you, create a new FTP site that can be opened for Read-only access by anonymous users. To do so, use the following steps:

1. Go to IIS 7 Manager. In the Connections pane, click the Sites node in the tree.
2. Right-click the Sites node in the tree and click Add FTP Site, or click Add FTP Site in the Actions pane.

3. When the Add FTP Site wizard appears:

• Enter "My New FTP Site" in the FTP site name box, then navigate to the "%SystemDrive%\inetpub\ftproot" folder that you created in the Prerequisites section. Note: If you choose to type in the path to your content folder, you can use environment variables in your paths.
• Click Next.

4. On the next page of the wizard:

• Choose an IP address for your FTP site from the IP Address drop-down, or choose to accept the default selection of "All Unassigned." Because you will be accessing this FTP site remotely, you want to make sure that you do not restrict access to the local server and enter the local loopback IP address for your computer by typing "127.0.0.1" in the IP Address box.
• You would normally enter the TCP/IP port for the FTP site in the Port box. For this walk-through, you will choose to accept the default port of 21.
• For this walkthrough, you do not use a host name, so make sure that the Virtual Host box is blank.
• Make sure that the Certificates drop-down is set to "Not Selected" and that the Allow SSL option is selected.
• Click Next.

 

5. On the next page of the wizard:

• Select Anonymous for the Authentication settings.
• For the Authorization settings, choose "Anonymous users" from the Allow access to drop-down. Select Read for the Permissions option.
• Click Finish.

6. Go to IIS 7 Manager. Click the node for the FTP site that you created. The icons for all of the FTP features display.

Summary

To recap the items that you completed in this step:

1. You created a new FTP site named "My New FTP Site", with the site's content root at "%SystemDrive%\inetpub\ftproot".
2. You bound the FTP site to the local loopback address for your computer on port 21, choosing not to use Secure Sockets Layer (SSL) for the FTP site.
3. You created a default rule for the FTP site to allow anonymous users "Read" access to the files.

Step 1: Configure the Passive Port Range for the FTP Service

In this section, you configure the server-level port range for passive connections to the FTP service. Use the following steps:

1. Go to IIS 7 Manager. In the Connections pane, click the server-level node in the tree.

2. Double-click the FTP Firewall Support icon in the list of features.

3. Enter a range of values for the Data Channel Port Range.

4. Once you have entered the port range for your FTP service, click Apply in the Actions pane to save your configuration settings.

Notes:

1. The valid range for ports is 1024 through 65535. (Ports from 1 through 1023 are reserved for use by system services.)
2. You can enter a special port range of "0-0" to configure the FTP server to use the Windows TCP/IP dynamic port range.
3. This port range will need to be added to the allowed settings for your firewall server.

Step 2: Configure the external IPv4 Address for a Specific FTP Site

In this section, you configure the external IPv4 address for the specific FTP site that you created earlier. Use the following steps:

1. Go to IIS 7 Manager. In the Connections pane, click the FTP site that you created earlier in the tree, Double-click the FTP Firewall Support icon in the list of features.

2. Enter the IPv4 address of the external-facing address of your firewall server for the External IP Address of Firewall setting.

3. Once you have entered the external IPv4 address for your firewall server, click Apply in the Actions pane to save your configuration settings.

Summary

To recap the items that you completed in this step:

1. You configured the passive port range for your FTP service.
2. You configured the external IPv4 address for a specific FTP site.

(Optional) Step 3: Configure Windows Firewall Settings

Windows Server 2008 contains a built-in firewall service to help secure your server from network threats. If you choose to use the built-in Windows Firewall, you will need to configure your settings so that FTP traffic can pass through the firewall.

There are a few different configurations to consider when using the FTP service with the Windows Firewall - whether you will use active or passive FTP connections, and whether you will use unencrypted FTP or use FTP over SSL (FTPS). Each of these configurations are described below.

Note: You will need to make sure that you follow the steps in this section walkthrough while logged in as an administrator. This can be accomplished by one of the following methods:

• Logging in to your server using the actual account named "Administrator".
• Logging on using an account with administrator privileges and opening a command-prompt by right-clicking the Command Prompt menu item that is located in the Accessories menu for Windows programs and selecting "Run as administrator".

One of the above steps is required because the User Account Control (UAC) security component in the Windows Vista and Windows Server 2008 operating systems prevents administrator access to your firewall settings.

Note: While Windows Firewall can be configured using the Windows Firewall applet in the Windows Control Panel, that utility does not have the required features to enable all of the features for FTP. The Windows Firewall with Advanced Security utility that is located under Administrative Tools in the Windows Control Panel has all of the required features to enable the FTP features, but in the interests of simplicity this walkthrough will describe how to use the command-line Netsh.exe utility to configure the Windows Firewall.

Using Windows Firewall with non-secure FTP traffic

To configure Windows Firewall to allow non-secure FTP traffic, use the following steps:

1. Open a command prompt: click Start, then All Programs, then Accessories, then Command Prompt.
2. To open port 21 on the firewall, type the following syntax then hit enter:

   netsh advfirewall firewall add rule name="FTP (non-SSL)" action=allow protocol=TCP dir=in localport=21

3. To enable stateful FTP filtering that will dynamically open ports for data connections, type the following syntax then hit enter:

   netsh advfirewall set global StatefulFtp enable

Important Notes:

• Active FTP connections would not necessarily covered by the above rules; an outbound connection from port 20 would also need to be enabled on server. In addition, the FTP client machine would need to have its own firewall exceptions setup for inbound traffic.
• FTP over SSL (FTPS) will not be covered by these rules; the SSL negotiation will most likely fail because the Windows Firewall filter for stateful FTP inspection will not be able to parse encrypted data. (Some 3rd-party firewall filters recognize the beginning of SSL negotiation, e.g. AUTH SSL or AUTH TLS commands, and return an error to prevent SSL negotiation from starting.)

Using Windows Firewall with secure FTP over SSL (FTPS) traffic

The stateful FTP packet inspection in Windows Firewall will most likely prevent SSL from working because Windows Firewall filter for stateful FTP inspection will not be able to parse the encrypted traffic that would establish the data connection. Because of this behavior, you will need to configure your Windows Firewall settings for FTP differently if you intend to use FTP over SSL (FTPS). The easiest way to configure Windows Firewall to allow FTPS traffic is to list the FTP service on the inbound exception list. The full service name is the "Microsoft FTP Service", and the short service name is "ftpsvc". (The FTP service is hosted in a generic service process host (Svchost.exe) so it is not possible to put it on the exception list though a program exception.)

To configure Windows Firewall to allow secure FTP over SSL (FTPS) traffic, use the following steps:

1. Open a command prompt: click Start, then All Programs, then Accessories, then Command Prompt.
2. To configure the firewall to allow the FTP service to listen on all ports that it opens, type the following syntax then hit enter:

   netsh advfirewall firewall add rule name="FTP for IIS7" service=ftpsvc action=allow protocol=TCP dir=in

3. To disable stateful FTP filtering so that Windows Firewall will not block FTP traffic, type the following syntax then hit enter:

   netsh advfirewall set global StatefulFtp disable

   
   
   

   More Information about Working with Firewalls

   It is often challenging to create firewall rules for FTP server to work correctly, and the root cause for this challenge lies in the FTP protocol architecture. Each FTP client requires two connections to be maintained between client and server:
   • FTP commands are transferred over a primary connection called the Control Channel, which is typically the well-known FTP port 21.
   • FTP data transfers, such as directory listings or file upload/download, require a secondary connection called Data Channel.
   Opening port 21 in a firewall is an easy task, but this means that an FTP client will only be able to send commands, not transfer data. This means that the client will be able to use the Control Channel to successfully authenticate and create or delete directories, but the client will not be able to see directory listings or be able to upload/download files. This is because data connections for FTP server are not allowed to pass through the firewall until the Data Channel has been allowed through the firewall.
   Note: This may appear confusing to an FTP client, because the client will seem to be able to successfully log in to the server, but the connection may appear to timeout or stop responding when attempting to retrieve a directory listing from the server.
   The challenges of working with FTP and firewalls doesn't end with the requirement of a secondary data connection; to complicate things even more, there are actually two different ways on how to establish data connection:
   • Active Data Connections: In an active data connection, an FTP client sets up a port for data channel listening and the server initiates a connection to the port; this is typically from the server's port 20. Active data connections used to be the default way of connecting to FTP server; however, active data connections are no longer recommended because they do not work well in Internet scenarios.
   • Passive Data Connections: In a passive data connection, an FTP server sets up a port for data channel listening and the client initiates a connection to the port.
   Note: Some FTP clients require explicit action to enable passive connections, and some clients don't even support passive connections. (One such example is command-line Ftp.exe utility that ships with Windows.) To add to the confusion, some clients attempt to intelligently alternate between the two modes when network errors happen, but unfortunately this does not always work.

   Some firewalls try to remedy problems with data connections with built-in filters that scan FTP traffic and dynamically allow data connections through the firewall. These firewall filters are able to detect what ports are going to be used for data transfers and temporarily open them on firewall so that clients can open data connections. (Some firewalls may enable filtering FTP traffic by default, but it is not always the case.) This type of filtering  is known as a type of Stateful Packet Inspection (SPI) or Stateful Inspection, meaning that the firewall is capable of intelligently determine the type of traffic and dynamically choose how to respond. Many firewalls now employ these features, including the built-in Windows Firewall.
   
   

Create a new site in IIS 7

The following article explains how to create a new website on your Windows server in IIS 7. IIS 7 (Internet Information Services) controls the configuration of each website on the server. There are two types of websites that can be configured, IP based sites and Name based sites*.


1. Log into your server through Remote Desktop Connection.

2. Click Start > All Programs > Administrative Tools > Internet Information Services (IIS) Manager.

3. Expand the server name.

4. Right-click Sites and choose Add Web Site…

5. Type in the Site Name. A description or the domain name is best to put into this field. This will automatically create an Application Pool for the site.

6. Enter or browse to the path where the website will have its root directory. This is the directory where the home page should go.

7. For the Binding, choose HTTP, choose an IP address that is free, leave the port as port 80, and enter in your domain name (i.e. www.domain.com) as the Host Name. Leave the checkbox for Start Web site immediately checked and click OK.

8. Go back to the IIS7 main screen and select the site under the Sites folder. Click Bindings… on the right sidebar so there is a host header for domain.com as well.

9. Click the Add button, choose HTTP, use the same IP address as setup in step 7, leave the port as port 80, and enter in your domain name (i.e.domain.com) as the Host Name. Click OK.

An IP-based website has a unique IP address therefore no other website can use this IP address. 

A name-based website shares a single IP address with each website on the server. You are able to make as many name-based sites as you wish with your single IP address.