3

We have a fleet of IIS 7.5 servers that manage our hosted product. Each generation of the product gets its own AppPool and its own site. Every generation is bound to thegeneration.oursite.com, plus one lucky website gets the default binding (which is the one customers actually hit, obviously). When we are ready to switch to the new site, we have a tool that attempts to switch the default binding from the old generation to the new one. The pattern for this is:

  1. Clear the bindings on all websites.
  2. Reestablish the custom bindings on all websites
  3. Set the default binding to the new active generation.

So far, so good. Our code to do this is simple and works great.

Well, almost. Here's the thing: no matter what we do, no matter how we try to structure things, IIS always shuts down the new default binding, complaining that there are now two sites with default bindings. This happens no matter whether we use the Microsoft.Web.Administration assembly or edit applicationHost.config. Notably, manually starting the site after the conflict warning works great, 100% of the time, and neither applicationHost.config nor the assembly interface actually show two sites with the default binding at any point.

How can we keep IIS 7.5 from shutting down when we swap default bindings? Is there really no way to do this?

EDIT: I was asked to clarify what I meant wth an example, so I'll walk through an actual upgrade of one project we're managing this way, Kiln.

So let's say we start off with two generations of Kiln that are active: Kiln1.0 and Kiln2.0. This means I have AppPools with those names and sites with those names. Basically customers are on Kiln1.0; only our testers and beta users are on Kiln2.0. Kiln accounts belong to subdomains, so to achieve this, the Kiln2.0 site has bindings for e.g. *:80:foo.kilnhg.com, *:80:bar.kilnhg.com, etc., and Kiln1.0 site has the binding *:80:* so that anyone who's not explicitly on the testing generation is on the new generation.

When we want to upgrade everyone to Kiln2.0, we want to delete the *:80:* binding on Kiln1.0 and create it on Kiln2.0. The issue I'm having is that every single way to do that shuts down Kiln2.0, with IIS claiming that the binding is duplicated. It's that particular binding that's causing the issue.

Improve this question
2
  • What do you mean by "Default Binding", a binding is just a binding. Can you add to your question a worked example of what you're doing?
    – Kev
    Jan 10, 2012 at 0:56
  • Sure; I gave a concrete (albeit simplified) example.
    – Benjamin Pollack
    Jan 10, 2012 at 13:52

1 Answer 1

Reset to default
0

It sounds like you might be a victim of IIS configuration update latency.

Typically, this can be avoided by either reducing the number of steps (eg, why clear then re-establish bindings? Just replace them in one go then commit the change), or adding wait states.

Yes, wait states. {Sleep 10 seconds} in the middle of the batch file/script/program would probably get it working too.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .