Redirecting subsite on same domain to other IIS using HTTPS

directoryhttpsiis-7redirect

I've seen many similar questions (and answers) on this subject, but none seem to be on exactly the same situation I am facing. Which is weird since I don't think it is that special, so forgive me if I haven't searched enough.

Anyway.
I have two websites which are on two IIS7, one facing WAN and one in the LAN. The WAN facing is already HTTPS-only.
I want to add the second website, but on the same HTTPS domain and SSL certificate, so that it becomes a subsite like: https://www.domain.com/subsite
How can I do a redirect or rewrite on the first IIS to the second one to make this work?
I don't think there is a standard IIS feature that can do this.
ISA server is not an option currently. But maybe another extension to IIS exists?

Done this numerous times on Apache, and am about to ditch IIS for Apache.

Best Answer

This is possible in IIS using the supported plugins ARR and URLrewrite. They install as integrated tools in the IIS Manager GUI.

If you install the latest ARR package you get URLrewrite bundled. The online documentation is somewhat lacking, but with a bit of tinkering what you want to do is achievable without too much hassle.

Even if the gui is quite friendly, my suggestion is to make sure you regularly save your applicationHost.config while testing, as the gui occasionally bugs out. This is true at least with ARR v2.5 which was the one I used when doing this. Then you have working text configs which you can copy/paste from each time you decide to clean-slate your config. This will save you a lot of time.

In the applicationHost.Config look especially for these XML elements:

<rewrite>
...
</rewrite>
<webFarms>
...
</webFarms>

The webfarms section is where your content locations defined in the gui end up, it is essentially config for a reverse-proxy load-balancer where a farm is a virtual service connection to one or more backend nodes. Similarly, the rewrite section is where you find your conditions for which content is to be fetched from which farm.

Here follows an actual configuration excerpt which does not match your use case entirely but which may serve as inspiration regardless. Possibly you only need to edit the second rewrite rule to match your scenario. The use case presented is for when the IIS is used as a pass-through proxy to two backend farms, dynamic content is served from the "htmlFarm", whilst requests for predefined static content such as images from the "imageFarm". The selection is done based on the beginning of the URI. If the URI starts with /images/ it is regarded as static content and routed to "imageFarm", else it is routed to "htmlFarm". In either case the IIS is presenting itself to the client as the one and only web server. A simple health check is also done in two different ways, one for each farm. This was just by way of experiment and I just include it as residual noise which nevertheless could be of use to you.

<rewrite>
        <globalRules>
            <clear />
            <rule name="Route all to htmlFarm" patternSyntax="ECMAScript">
                <match url=".*" />
                <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
                    <add input="{HTTP_HOST}" pattern="(.*\.)?site01.com" />
                </conditions>
                <action type="Rewrite" url="http://htmlFarm/{R:0}" />
            </rule>
            <rule name="Route /images/* to imageFarm" stopProcessing="false">
                <match url="images/.*" />
                <conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
                <action type="Rewrite" url="http://imageFarm/{R:0}" />
            </rule>


        </globalRules>
</rewrite>
....
<webFarms>
    <webFarm name="htmlFarm" enabled="true">
        <server address="192.168.50.77" enabled="true">
            <applicationRequestRouting weight="100" />
        </server>
        <server address="192.168.50.78" enabled="true" />
        <applicationRequestRouting>
            <loadBalancing algorithm="WeightedRoundRobin" />
            <healthCheck url="http://site01.com" responseMatch="Testing" />
        </applicationRequestRouting>
    </webFarm>
    <webFarm name="imageFarm" enabled="true">
        <server address="192.168.50.81" enabled="true">
            <applicationRequestRouting weight="100" />
        </server>
        <server address="192.168.50.82" enabled="true">
            <applicationRequestRouting weight="100" />
        </server>
        <applicationRequestRouting>
            <healthCheck url="http://site01.com/images/test.txt" responseMatch="WillTest" />
            <loadBalancing algorithm="WeightedRoundRobin" />
        </applicationRequestRouting>
    </webFarm>
    <applicationRequestRouting>
        <hostAffinityProviderList>
            <add name="Microsoft.Web.Arr.HostNameRoundRobin" />
            <add name="Microsoft.Web.Arr.HostNameMemory" />
        </hostAffinityProviderList>
    </applicationRequestRouting>
</webFarms>

Again not in your use case but nevertheless: a limitation in ARR is that even though an IIS node with ARR can provide redundancy for the backend, it will in itself be a single point of failure. You need two or more identically configured IIS/ARR nodes with NLB, or a separate load balancer in front in order to overcome this. Web-fronts-as-usual in other words :-)

We ultimately ditched IIS/ARR for Apache, but more by way of political accident which caused a major outbreak of office humour. I really don´t favour either above the other as I find both to function and perform very, very well. Monitoring in Apache however is abysmal in direct comparison with IIS, and in no way do I wish that comment to be a flame to anything. It´s just my direct experience with all respect to other possibly differing opinions on the subject.

Best of luck!

Related Topic