IIS 7.x Shared Configuration–Advanced Tips and Tricks-Week 29

You can find this week’s video here.

This video covers advanced under the hood tips and tricks for IIS Shared Config. If you are already familiar with Shared Config and want to go deeper, this video is for you.

We dig in deeper to IIS 7 (7.5) Shared Configuration in this week’s lesson. If you are already familiar with IIS Shared Config, or have seen last week’s lesson, than this will cover more of the internals. This week is a bit different in that Scott discovers a couple tricks while recording this video, so join with him on an adventure to learn more about this powerful feature in IIS. Advanced topics include the series issue with IIS backups and shared configuration, where the redirection meta information is saved, and how to workaround the password issues when joining servers back to shared configuration after maintenance.

This is now the 4th week in a mini-series on web farms, and the 29th week of the entire series. You can view past and future weeks here: http://dotnetslackers.com/projects/LearnIIS7/

You can find this week’s video here.

2 Comments

  • 1. Need probably to explore further what happens when encryption key is actually necessary for shared config. Why are those in a first place if they seems not providing any benefit (since it's actually is not used for any encryption).
    2. What is prefered method in farm which is using shared configuration to deploy changes? Do you take one server offline, disable shared config, make changes on local machine, then copy those files from %system% over existing ones in shared config location to enable those on the rest of the nodes?

    Thanks,
    G

  • Hi G,

    Bummer that I wasn't very clear in the video about this. A disadvantage with videos is that it's hard to make quick edits. :)

    The encryption key *is* necessary, but only for the very first time a server is added to the farm. On the very first time it connects, it uses the encryption key to place the machine key on that server so that it can read/write the same encrypted data as the other servers. After that's been done once though, the encryption key is never needed for subsequent connections to shared config.

    For your 2nd question, watch for this week's video on staggered installs. That's different than site content though so it may not fully answer your question. For web content, you can take a server out of rotation while still keeping shared configuration enabled ... that is unless you want to make IIS changes that you don't want to impact the live site yet.

    I may cover it later in the year, but what I do is powerful but fairly difficult to set up the first time. I use what I call Site Instances where multiple sites live beside each other and I push staging to a different instance. Then using the load balancer (ARR in my case) I swap instances with zero downtime. That allows pushing the site and testing it during the day, and then an instant deployment whenever it's ready. That prevents staggered deployments. I realize my answer is just a teaser with limited details but hopefully it gives you some ideas on options for deployments.

Comments have been disabled for this content.