Won Yoo's Blog

Workaround: Running ASP.NET 1.1 on Vista SP2/WS08 SP2

2009-06-18T22:01:00Z

Many of you have probably read the article on how to install ASP.NET 1.1 on IIS7 on Vista and WS08 (The article can be found at http://learn.iis.net/page.aspx/472/how-to-install-aspnet-11-with-iis7-on-vista-and-windows-2008/).

While above works great on Vista/Vista SP1/WS08 RTM, if you try to run ASP.NET 1.1 on Vista SP2/WS08 SP2, you may have experienced the following error if you are on a 64-bit OS:

There was an error while performing this operation.

Details:

Filename:
\\?\C:\Windows\system32\inetsrv\config\applicationHost.config
Error:

Here is the problem.

In order to support .NET 4.0 Framework, IIS team has released a hotfix (http://support.microsoft.com/kb/958854) which is also included in SP2. At the root of the problem is that this hotfix allows the IIS runtime to read the correct version of .NET Framework configuration based on the .NET Framework version that is associated with the application pool. For example:

.NET Framework version 1.1: the config location is %windir%\Microsoft.NET\Framework\v1.1.4322\CONFIG
.NET Framework version 2.0: the config location is %windir%\Microsoft.NET\Framework\v2.0.50727\CONFIG
.NET Framework version 4.0: the config location is %windir%\Microsoft.NET\Framework\v4.0.nnnnn\CONFIG

The problem is that when the runtime tries to load the corresponding configuration, it doesn't take the bitness of the application pool into the consideration. As you know, ASP.NET 1.1 is only supported on 32-bit. So if you have a 64-bit OS, in order to run ASP.NET 1.1, you have to enable 32-bit applications in the application pool. So, with the QFE/SP2 on 64-bit OS (and only on 64-bit OS), the runtime is incorrectly looking for the 1.1 version of the configuration under Framework64, which does not exist.

Workaround:

Create the Framework64 directory for 1.1
md \windows\microsoft.net\framework64\v1.1.4322\config\
Copy the 32bit config to 64bit config location created in step 1.
copy \windows\microsoft.net\framework\v1.1.4322\config\machine.config \windows\microsoft.net\framework64\v1.1.4322\config\

In the spirit of full disclosure, without the hotfix/SP2, the behavior was still incorrect on Vista/Vista SP1/WS08 RTM in that the runtime was alreays reading the 2.0 configuration although the application pool is configured to use .NET 1.1. (Because the runtime was always reading the 2.0 config regardless of the .NET Framework version that is associated with the application pool. This was the bug that hotfix/SP2 tried to address as part of supporting .NET 4.0, but it didn't quite consider the fact that ASP.NET 1.1 is only available in 32-bit.) This bug in Vista/Vista SP1/WS08 RTM may not have been too obvious to those running ASP.NET 1.1 on 64-bit Vista/Vista SP1/WS08 RTM unless you have significant/specific settings/differences between 1.1 and 2.0 configurations.

Hotfix and Security Update List: Windows Server 2008 SP2 and Windows Vista SP2

2009-06-18T21:35:00Z

Not sure if anyone has seen this, but yesterday, Microsoft posted the full list of all Hotfixes (QFEs) and Security updates that have been rolled into Vista SP2. The list can be downloaded from the Microsoft Download Center at http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=d8b2cf4b-a2df-4664-8dd8-e840001e33f3.

For IIS, you will want to look under the Server Technologies, although unfortunately, there isn't a way to just filter for IIS QFEs.

Vista/Windows Server 2008 Service Pack 2 (SP2) RC

2009-03-27T22:20:00Z

In March, Vista/Windows Server 2008 SP2 RC was made public. (See my blog post on SP2 Beta release here).

From the IIS perspective, since the SP2 Beta release, we have been focusing on stability and reliability. So there aren't any significant functional changes that we introduced in RC. One exception is:

Specify root of a drive as the documents root.

The root of a drive (ie. d:\) can be used as the documents root.

We have had customer requests around this and we decided to enabled that in RC. (For other IIS changes in SP2, refer to the Beta blog post).

There is one behavior that I would like to note. In SP2 Beta as well as in RC, the IIS team has introduced a new identity called ApplicationPoolIdentity which can be used to run application pools. In order to keep the functional behavior the same, if you create a new site using the inetmgr, the corresponding application pool will have NETWORK SERVICE as the identity. However, you can change the process model from NETWORK SERVICE to ApplicationPoolIdentity after the application pool has been created.

Now, for some reason, let's suppose that you have decided to un-install SP2. The un-installation will complete successfully, but you may find that your IIS instance is failing to start. This may happen if you had configured any of the application pools to use ApplicationPoolIdentity. Now that SP2 is removed, there is no such identity after SP2 is un-installed.

To work around this, simply locate the following from applicationHost.config and change the process identity model to a valid one, such as NETWORK SERVICE.

Change from:

<processModel identityType="ApplicationPoolIdentity" />

To (example: NETWORK SERVICE):

<processModel identityType="NetworkService" />

The official SP2 RC site is here and you can download RC from:

ISO for Windows Server 2008 x86/x64/ia64 and Windows Vista x86/x64
x86 for Windows Server 2008 and Windows Vista x86
x64 for Windows Server 2008 and Windows Vista x64
IA64 for Windows Server 2008 ia64

Microsoft Application Request Routing (ARR) Version 2 for IIS7 Beta 1 has been released.

2009-03-18T18:01:00Z

Following the ARRv1 RTW release last month, the ARR team has released ARRv2 Beta1 release today. (The "official" announcement can be found here.)

ARRv2 is an incremental release that has all the features of ARRv1, but we added a support for disk cache. What is really exciting about this feature is that now we can start thinking about using ARR as a cache proxy. (Read about the disk cache feature here.) Also, we have added support for CARP (Cache Array Routing Protocol) and cache hierarchy management that will enable customers to build a network of ARR cache nodes in CDN (Content Delivery Network)/ECN (Edge Cache Network).

You can learn more about ARRv2 Beta 1 here.

Downloads:

Microsoft Application Request Routing Version 2 for IIS 7.0 Beta 1 (x86) here.
Microsoft Application Request Routing Version 2 for IIS 7.0 Beta 1 (x64) here.

Support:

For Beta releases, the support is provided via this forum. It is also a great place to ask for feature requests as we are currently working on Beta2.

Benefits of host name affinity provider in ARRv1 RTW

2009-02-24T01:51:00Z

As you know, ARRv1 has RTW'ed last week.

Download the RTW release from:

One of the features that we have added between ARRv1 RC and ARRv1 RTW is host name affinity provider. This feature is used only when host name affinity is enabled in shared hosting scenarios. The feature is located at Server Farm -> Server Affinity -> Host Name Affinity:

There are two providers that are available out of the box:

Microsoft.Web.Arr.HostNameRoundRobin
Microsoft.Web.Arr.HostNameMemory

They are all documented in the walkthroughs (How to configure Microsoft.Web.Arr.HostNameMemory is here.) and online help so I won't repeat what they are in this blog.

What I would like to share are some of the findings and the benefits of these providers.

ARRv1 RC:

In ARRv1 RC, without the providers, the host name affinity decision was made using the same load balance algorithm that was selected for the server farm. In our environment, where we have 4 application servers behind ARR, below is what we have seen:

Above graph is showing the available memory on each of the 4 servers in the server farm and as you can see, they are not evenly distributed. This is because the load balance algorithms are largely based on the number and size of requests/responses and the responsiveness of the servers. More explicitly, they do not take the memory consumption as a decision point.

This is not ideal, especially in a shared hosting environment, where 100's or even1000's of sites are competing for the same resources on the shared server. With running ASP.NET application, we also know that the application servers are memory bound.

In order to address this challenge, in ARRv1 RTW, we have introduced the two providers mentioned above.

ARRv1 RTW: Microsoft.Web.Arr.HostNameRoundRobin

Microsoft.Web.Arr.HostNameRoundRobin tries to evenly distribute the number of affinitized servers, but it still does not take the memory consumption as a decision point. Using Microsoft.Web.Arr.HostNameRoundRobin provider, we have seen a dramatic change in the distribution of active worker processes:

Note the difference between before and after.

However, it still didn't result in an even distribution of memory consumption on the application servers:

It is a good improvement, but we can do better.

ARRv1 RTW: Microsoft.Web.Arr.HostNameMemory

Microsoft.Web.Arr.HostNameMemory provider queries the memory utilization of the application servers in the server farm using WMI (Refer to this walkthrough for details on how to configure Microsoft.Web.Arr.HostNameMemory).

Using Microsoft.Web.Arr.HostNameMemory, the number of affinitized servers are not as evenly distributed as Microsoft.Web.Arr.HostNameRoundRobin:

However, the memory utilization across the application server is evenly distributed:

Since Microsoft.Web.Arr.HostNameMemory provider relies on WMI, it is true that the application servers in the server farm must be Windows. Also, the configuration of Microsoft.Web.Arr.HostNameMemory provider is more involved than that of Microsoft.Web.Arr.HostNameRoundRobin.

Having said above, there are other great use cases for ARR. For this and other great features of ARR, checkout the RTW release at http://www.iis.net/extensions/ApplicationRequestRouting.

The Microsoft Application Request Routing (ARR) Version 1 for IIS7 has been released to web (RTW).

2009-02-16T23:41:00Z

This is the official release for ARR Version 1 for IIS7 and it is now fully supported by Microsoft Support.

Overview:ARR Version 1 for IIS7 is a proxy based routing module that forwards HTTP requests to content servers based on HTTP headers and server variables, and load balance algorithms. It is designed for web server administrators and hosting providers and to increase Web application reliability and scalability. ARR also enables shared hosters to maximize resource utilization on application servers and reduce management costs for server farms.

Balance web requests more efficiently across servers to maximize resource utilization.
Increase Security and Scalability of Application Servers.
Optimize and scale server capacity through client and host name affinity.

Download the RTW release from:

What’s new in RTW:

Host name affinity providers: Optimize and manage how to affinitize host names.

Round Robin provider.
Memory based provider.

Contextual online help: Targeted help contents.
Manual override of health status: Web server administrators can manually override the results from URL and live traffic tests.
Specify port numbers on application servers: Using the UI, HTTP and HTTPS ports can be defined for application servers.
Improved least response time load balance algorithm.
Support readiness: Support is provided by Microsoft Support.

Documentation:

Install Application Request Routing
Define and Configure an Application Request Routing Server Group
HTTP Load Balancing using Application Request Routing
- Includes using health monitoring and client affinity
Configure 3-tier deployment architecture using Application Request Routing
Pilot Program Management using Application Request Routing
Shared Hosting using Application Request Routing
- Memory based provider
- Using Microsoft External Cache for IIS7
Using Failed Request Tracing Rules to Troubleshoot Application Request Routing
High availability at ARR tier
- ARR and NLB
- ARR and Hardware Load Balancer

Support:

The support is now provided by Microsoft Support.
The existing ARR forum will continue to exist and the product team will continue to moderate the forum.

Vista/Windows Server 2008 Service Pack 2 (SP2)

2009-02-10T05:12:00Z

In December 2008, Vista/Windows Server 2008 SP2 beta was made public. Yes, it is the first service pack for Windows Server 2008, but it is named SP2 since Windows Server 2008 RTM is really Vista SP1. In this blog post, I will high light some of the key changes for IIS 7.0 in SP2. (For more information on SP2 in general, here is the official SP2 site.)

Request Filtering Update

The request filter is now updated to include the following features:

Requests can be blocked based on query string sequences.
Rules can be scoped by the file extension in the request.
It is possible to declare specific URLs that are exempt from filtering.

These updates bring the Request Filter to feature parity with UrlScan 3.1.

Application pool identity.

SP2 introduces a new and temporary account called appPool identity for running application pools. On the local machine, this virtual account behaves just like a local user account, making it more secure than NETWORK SERVICE by providing further isolation between application pools. On the network (ie. accessing remote resources), it behaves like NETWORK SERVICE by assuming the machine's identity.

Custom errors are delegate-able.

This is something that shared hosters have been asking for since Windows Server 2008 RTM. With SP2, custom errors are delegation safe by allowing relative paths.

In addition to above, there are several bug fixes, including all the QFEs that we have done since Windows Server 2008 RTM.

SP2 beta can be downloaded from:

ISO for Windows Server 2008 x86/x64/ia64 and Windows Vista x86/x64
x86 for Windows Server 2008 and Windows Vista x86
x64 for Windows Server 2008 and Windows Vista x64
IA64 for Windows Server 2008 ia64

Meaning of "minimum servers" in Application Request Routing

2009-01-26T23:17:00Z

The product team is currently working on ARRv1 RTW and online help, in addition to the walkthroughs, will be part of this release effort.

That said, it has come to my attention that the "minimum servers" (available on Health Test page) has not been documented very well. (More info on ARR is here. You can also download x86 ARR here and x64 ARR here.)

As you know, one of the goals of ARR is to provide high availability among application servers. ARR achieves this by 1) monitoring the health of the application servers and 2) forwarding requests only to the healthy servers. Sounds simple enough, but it is actually a bit more complicated than that. Let's suppose that you have 10 application servers in a server farm where ARR is responsible for load balancing the requests. Given your traffic load, let's also suppose that you need at least 5 healthy servers at any given time in order to sufficiently handle the normal amount of traffic.

In a such environment, if 2 of the servers become unhealthy, there is no real impact on your environment because you still have 8 healthy servers that can handle the traffic. However, what happens if you have less than 5 healthy servers, say only 3 servers are healthy? What is the desired behavior? Given that you need at minimum 5 healthy servers to service the normal amount of traffic, having only 3 healthy servers isn't sufficient. I am over simplifying the problem but largely, there are one of the two outcomes:

Honor the health of application servers and send all requests to 3 healthy servers. In this case, you are overloading the 3 remaining healthy servers and most, if not all, of your end users will have bad experiences. Also, depending on the resiliency of the application servers, the experience may get even worse over time.
Disregard the health of application servers and load balance as usual. In this case, some requests are being routed to the healthy servers and some are being routed to unhealthy servers, based on the load balance algorithm. While is is not ideal, this is a better alternative than the first because only some of your end users will have bad experiences.

In order to address such situations, ARR has introduced the concept of "minimum servers" which represents the minimum number of healthy servers that you must have in your environment before it starts to disregard the health of the application servers to provide services to some end users without bringing down the entire service. In above example, the "minimum servers" value would be set to 5.

Shared configuration and password expiration.

2009-01-26T22:15:00Z

Most of you have probably heard of shared configuration. It is a simple and convenient way to centralize IIS configuration among multiple IIS instances. (More info on shared configuration can be found here.)

A step in setting up shared configuration is to provide a user credential that can be used to access the shared configuration. Now, what happens when the password changes for the user? Naturally, the IIS instances that are using the shared configuration will no longer be able to access the shared configuration on a file share and, therefore, they won't work properly. So, in order to fix this problem, you may be thinking that all you need to do is to open the IIS Manager and just update the password. You may be right, except that you have a chicken and an egg problem.

Although IIS Manager launches successfully, when you try to connect to the server, you will see the following error:

You guessed it. The IIS Manager is unable to read the configuration because it no longer has the access to the file share where the configuration file is located, hence the chicken and the egg problem.

Before we discuss how you can workaround this problem, we will first need to understand how the shared configuration works. Before the IIS config system loads applicationHost.config, it relies on redirection.config to see if shared configuration is enabled or not. Below is an example of redirection.config (which is located at %windir%\system32\inetsrv\config\):

<configuration>

    <configSections>
        <section name="configurationRedirection" />
    </configSections>

    <configProtectedData>
        <providers>
            <add name="IISRsaProvider" type="" description="Uses RsaCryptoServiceProvider to encrypt and decrypt" keyContainerName="iisConfigurationKey" cspProviderName="" useMachineContainer="true" useOAEP="false" />
        </providers>
    </configProtectedData>

    <configurationRedirection enabled="true" path="\\server\folder" userName="removed" password="[removed]" />

</configuration>

The IIS config system looks at the redirection.config file first.

If configurationRedirection is enabled, then it will try to read the applicationHost.config file from the path using the userName and password.

If configurationRedirection is disabled, it will try to read the applicationHost.config from the local file system. So, in order to temporarily get around the chicken and the egg problem, open the redirection.config in the notepad and set enabled="false". Doing so will effectively take this IIS instance out of shared configuration. More importantly, it will now allow you to launch the IIS manager and connect to the server successfully.

After launching the IIS manager, navigate to Shared Configuration page and enable shared configuration. Once enabled, update the password fields with the new password and Apply:

Now repeat the same steps in remaining IIS instances that are using the shared configuration.

Setting up Shared configuration on IIS 7.0

2009-01-13T02:59:00Z

Problem: When IIS 7.0 server is configured to work in shared configuration mode then configuration files are stored on a file share. This configuration is recommended for setting up web farms. But in case file share goes offline, the whole set up fails and web servers stop responding. Moreover when the file share comes up again, IIS server is not able to detect it gives following error message:

HTTP Error 500.19 - internal server errorThe requested page cannot be accessed because the related configuration data for the page is invalid.

We have to do an IISreset to start the web servers again after this.

Resolution: Follow the below given steps to set up shared configuration with offline files (client side caching) enabled.

Step 1: On the Web server, in Control Panel, open Offline Files.

Step 2: In the Offline Files dialog box, click Enable Offline Files. Do not reboot the machine yet.

Step 3: Ensure that the cache is set to read only by running the following command:REG ADD "HKLM\System\CurrentControlSet\Services\CSC\Parameters" /v ReadOnlyCache /t REG_DWORD /d 1 /f

Step 4: Reboot the Web server.

Step 5: Browse to the file share folder from web server. Right click and select “Always Available Offline”.

Step 6: Go to control panel -- > Offline Files. Select Schedule option.

Step 7: Schedule offline file sync after every 1 day or as per the requirement. This could be in minutes too. Even without setting up any scheduler, the moment I change anything in applicationhost.config file, it is reflected on the web server.

Now the web server works fine even if the file share is offline and there is no need of IISReset now.

Many thanks to Amol Mehrotra for helping with the content.

Application Request Routing Release Candidate (RC) has been released

2008-11-14T02:08:00Z

Today, IIS team has made the Application Request Routing (ARR) RC for IIS 7 available for download. This is the last major milestone release before the Release To Web (RTW) release. In addition to the feature improvements based on customer feedback, this release has been tested for stability and performance. As such, it has the quality level suitable for production deployment. During the RC period, the support will continue to be provided via the ARR forum.

Download the RC release:

What's new in RC?

Shared hosting and elastic scalability: Ability to specify different number of servers to utilize per host name. Increase and decrease the number of servers in real-time.
Host name affinity routing table: View where requests have been routed based on server name and host name.
High availability at ARR tier: Make ARR tier fault tolerant using hardware load balancers and NLB.
State management using Microsoft External Cache for IIS 7.0: Leverage External Cache to share runtime state between multiple ARR servers.
New and improved UI: Better usability based on Web farm framework.
APIs for monitoring and managing ARR: ARR programmability.
Kernel caching: Achieve higher throughput by caching static contents.
UI integration with URL rewrite: Tighter user experience between ARR and URL rewrite.

Documentation

All the documentations have been updated accordingly for the RC release. Start from the TOC.

Support

During RC, the support will continue to be provided via the ARR forum.

Video walk-through for Application Request Routing (ARR)

2008-09-29T04:05:00Z

A couple of weeks ago, I put together a video walk-through of Application Request Routing.

The video is about 45 minutes long and it highlights the key features and scenarios that were included in CTP1 release which can be downloaded from:

Application Request Routing x86

Application Request Routing x64

If you have further comments, questions, or suggestions, please feel free to use the forum.

Thanks.

Relationship between Application Request Routing and URL Rewrite modules

2008-07-27T05:34:00Z

As most of you know by now, Application Request Routing (ARR) CTP1 was released in early July. (Download x86 here and x64 here. Support is available via this forum.) ARR relies on the URL Rewrite module for inspecting the incoming HTTP requests and making the routing decisions based on the rewrite rules. These two modules work together via an extensibility point in ARR and the same extensibility can be used for routing HTTP requests via other routing logic.

First, let me explain how ARR works with URL Rewrite module. As the diagram below illustrates, both the URL Rewrite module and the ARR are invoked in the same request pipeline. The key point to note is that the URL Rewrite module subscribes to a notification that comes before ARR.

So as the request is being processed through the pipeline, URL Rewrite is applied first. It inspects the HTTP request and tries to apply the rewrite rules and conditions. If the rules for ARR match the request, then it calls a setURL API to rewrite the URL with the server group name as the destination (ie. http://<server group name>/{R:1}) As the rewritten URL makes its way through the pipeline, ARR is applied next. ARR detects that the rewritten URL matches the server group name that has been defined. Given what ARR knows about the server group, it applies the settings, including a load balance algorithm, for the server group and routes the request to one of the content servers defined in the server group.

That said, ARR relies on an external module to determine which server group to route the HTTP requests to. The URL Rewrite module is one such external module that can be used to determine the destination server group based on URL rewrite rules. Other modules can be written, for example, to route the HTTP requests based on the user profile or geo approximity to the requested content resources. Below is an example of how requests from a user may be routed to an appropriate OWA (Outlook Web Access) server based on where the user's mailbox is located:

ARR is a native module, but the external module that determines the server group can either be a native module or a managed module, thanks to the integrated pipeline in IIS 7.

IIS Extensions and servicing

2008-07-26T08:33:00Z

This week, IIS team has released two servicing patches for the following IIS Extensions:

FTP for IIS 7.0 (KB955136)

WebDAV for IIS 7.0 (KB955137)

They are the first servicing releases that the IIS team has done for IIS Extensions and I wanted to take this time to explain how we plan on servicing IIS Extensions and highlight some of the key differences between the Windows OS components servicing and IIS Extensions servicing.

Deployment technology: I have written a few blogs about CBS (component based servicing). CBS was first introduced in Windows Vista and for both Windows Vista and Windows Server 2008, CBS is how operating components, including IIS, are serviced. For IIS Extensions, the deployment technology is MSI (Microsoft Installer) which is the most common way of installing applications on Windows OSes. An update to a MSI is done via MSP (Microsoft Installer Patch) and the IIS Extension servicing releases are packaged in MSPs.

Scope and frequency: The servicing Hotfixes (also sometimes referred as QFEs - Quick Fix Engineering) for operating systems are targeted in that one Hotfix addresses one specific bug. Also, because the scope is small, the turn-around time is relatively quick, depending on the priority and the severity of the bug and the associated SLA (Service Level Agreement). With IIS Extension servicing, as you may have noticed from the KB articles for FTP and WebDAV, the MSPs may contain one or more bug fixes. Naturally, the frequency of IIS Extension servicing releases will vary based on the priority and the severity of the bugs and the scope of the release, determined both by the number of bug fixes and the complexities.

Distribution: Typically, the OS Hotfixes are made available to customers who contact the Microsoft support team. As noted above, the Hotfixes, by definition, address very specific and targeted problems. Given this nature, most Hotfixes are not applicable to every user of Windows. There are exceptions, such as security fixes, and in those situations, we make the bug fixes available to the general public. For IIS Extension servicing releases, they are made publicly at Microsoft Download Center.

SSL off-loading in Application Request Routing

2008-07-11T05:01:00Z

One of the features that has not been called out explicitly in Application Request Routing (ARR) documentations is SSL off-loading. This is a feature in which the communications between the clients and the ARR server are done via SSL while the communications between the ARR server and the content servers are done via clear text. In this scenario, SSL is terminated at the ARR server.

This feature is designed to better utilize the resources on the content servers. The task of decrypting and encrypting SSL requests and responses is "off-loaded" to the ARR server and the cycles saved by not performing such task can be spent on process additional user requests.

So, how do you configure SSL off-loading in ARR? We will work on enhancing the user experience in later releases, but in CTP1, here is how you can do it. As you may know, ARR relies on URL Rewrite module to inspect the incoming requests and determine which server group to route the requests based on the rewrite rules. Given this, in order to route all traffic to the server group via HTTP, you can simply state this in the URL Rewrite module UI as shown below:

In some cases, though, you may not want to use SSL off-loading. One such example would be if the applications on the content servers expect certain communications to be requested via SSL. (If this is true, in most cases, appropriate changes are made to the applications so that SSL off-loading can be used. For example, Windows Live ID - formally Passport ID - has specific APIs for enabling SSL off-loading. However, this may not be possible in all situations. For instance, it is possible that the deployment schedule of ARR is not aligned with the deployment schedule of the updated applications.)

In such situations, ARR can be configured so that SSL off-loading is not used. Note, though, that ARR does not support CONNECT tunneling. The SSL is still terminated at the ARR server, but the ARR server can be configured so that it will make SSL connections with the content servers. To do this, you will need to write two rules in the URL Rewrite module.

First, we are going to determine if the request is made via SSL. If so, it will forward the request to the content server via SSL:

Note that the Stop processing of subsequent rules check box is selected.

Secondly, we are going to route the remaining requests via HTTP:

In either of the two cases above, appropriate server certificate must be imported on the ARR server. In the SSL off-loading case, however, the server cerficiate does not need to be imported on the content servers. In the second case where the SSL off-loading is not used, the server certificate must be imported on all of the content servers.