I blogged a long time back about using AppCmd to back up and restore IIS 7.0 server configuration.

Bill also just posted about backing up and restoring configuration, where he does a great job of telling you why you need to make backups and the options you got between manual AppCmd backups and leveraging automatic Configuration History service backups.

This reminded me of a question I often get about backing up and restoring configuration when IIS 7.0 is being used in the Shared Configuration mode.  In this mode, the applicationHost.config file is stored on a UNC share to allow multiple IIS 7.0 servers to share a single configuration file.

Let me answer this question by way of illustrating what happens when you run "AppCmd Add Backup" when the IIS 7.0 server is using local configuration (default), vs shared configuration.

In the local configuration case, the tool will back-up the following files in the %windir%system32inetsrv directory:

1. configapplicationHost.config
2. configadministration.config
3. configredirection.config
4. configmetabase.xml
5. configmbschema.xml
6. All custom schema files under the configschema directory

In the shared configuration case, the tool does the same thing.

So, what’s my point? It’s simply that AppCmd backup commands always work with backups of the local server configuration.

This means that in the shared configuration case, the tool WILL NOT back up or restore the configuration located on the UNC share. However, it will back up and restore the local redirection.config file, which contains the details about where the shared configuration file is located.

So, if you were using local configuration at the time of backup, then moved to shared configuration, and then restored the backup, you’ll be back to your local configuration. If you were using shared configuration at the time of backup, then moved to local, then restored, you’d be back to using shared configuration (whatever it may be at this time), and your local applicationHost.config will be reset to the one saved at time of backup.

There is a specific reason for this design.  Imagine this scenario – you have a web farm with multiple servers using a single shared configuration file.  At some point, someone starts having trouble with one of the servers, and restores a prior configuration backup – all of a sudden, all other servers are falling over because their configuration has been reset to a configuration state that is local to the one server. Besides the fact that this could be unexpected and undesired, it could also cause all kinds of serious issues, including encryption key mismatches and configuration for features that are not installed on other web farm servers.

In addition to this, be aware that the Configuration History service will not back up configuration when in shared configuration mode.

So, moral of the story is, when using shared configuration, it is your responsibility to manage the backups of the shared configuration files.

With that in mind:

* DO perform manual backups with AppCmd (or use scheduled tasks, etc) to back up the local state even when using shared configuration. This way, you can restore the redirection.config details later if needed.

* DO perform manual backups of the shared configuration each time you make changes (or on a regular schedule), and perform manual copy of those files to the share to restore the web farm’s configuration.

* DO NOT expect to restore the web farm’s configuration by using AppCmd restore backup commands.

You can still depend on the local backup facilities to restore your server to its original local state, or restore the shared configuration settings as needed.

The only caveat to this is that if you are directly sharing configuration of one of the servers to other servers (so it’s effectively local for the “master” server), then backup/restore operations on that server will affect the entire web farm. However, I do not generally recommend doing this has its own set of limitations out of the scope of this post.

Hopefully this clarifies things a bit.

Thanks,

Mike

Last week, the IIS team released bit-rate throttling module to the web.

As the self-proclaimed daddy of the project (I designed and wrote the initial prototype in early 2007), I am very thrilled to see it out. The new IIS media team folks have done a great job getting it production ready and rounding out the feature-set, which you can review in its full glory in Vishal's post.

Download links:
- 32 bit - http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1640
- 64 bit - http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1641

So what is the bit-rate throttlng module about? In essense, it is an effective solution for saving a LOT of bandwidth for web sites serving media. 

Imagine this scenario - a client connects to your video site, clicks on your featured video, watches 5 seconds of it to realize they have no interest in watching further, and move on to the next video.

In those 5 seconds, the server could have sent out 5 minutes worth of the video, and you paid for 5 minutes worth of bandwidth. With the bit-rate throttler + media bitrate detection, the server would only end up sending a little over 5 seconds worth, and you would end up paying only for what was used.

This translates to VERY major savings for most video sites.

The way I originally wrote the module, it was actually comprised of two separate modules: a throttler, and the media bit-rate detector. Eventually these got combined into a single module, but it is still useful to think about it from the point of view of two separate features.

• The throttler component is a mechanism to control the rate at which IIS sends out the response for any request to the server.  It works in conjuction with another module or configuration that instructs it to do two things for any response: pre-send any configured amount of data without restricting the response rate, and then send the rest of the response at the configured rate.
• The bit-rate detector is a separate module that can parse common media files, and determine their encoded rate (many video file formats, including ASF, include the maximum encoded rate in the header of the media file). It can then configure the throttler to send that media file at a rate that is just over the encoded rate.

It's also worth noting that the throttler uses a high-performance asyncronous loop to push the data out, without tying up server threads for what can be a very long operation. For responses coming from files (like most large video files), it also does not need to read the content's of the file being sent into memory, instead just instructing http.sys to send portions of the file out to the client at a time.  Because of this, it won't significantly affect your memory usage. While this mechanism is not as efficient as http.sys's own site-wide bandwidth throttling (which cannot be used to do what we are trying to accomplish here), it is pretty much as lean as it can be.

While these two components play different roles, the current bit-rate module release combines them into a single module.  Still, thanks to the flexibility of configuration, you can set both static rules for throttling abitrary content on your site, as well as rules that can automatically detect the bit-rate of media files.

In addition to controlling the response rates, the bit-rate throttling provides the following features:

• Fast Start - the ability to send the first part of the media file without rate limiting, to seed the playback buffer in the player and make sure that playback can begin as soon as possible (most players try to prebuffer a certain amount of the video, often 5 seconds, before starting playback). This also insures that if the connection suffers a hickup, the playback can continue uninterrupted
• Disconnect detection - when the client stops watching the video, goes to another page, or closes the video, the bitrate throttler detects the connection closure and stops sending the file.
• Built-in support for detecting the playback rate for common media formats, including .asf, .avi, .flv, .m4v, .mov, .mp3, .mp4, .rm, .rmvb, .wma, and .wmv.
• Ability to configure static throttling rates, and media auto-detection rates at any configuration level.

It is also possible to add support for additional media formats by using the configuration that tells the module how to find the bitrate in the mediate file. Finally (as I intended from the very start), the module retains the ability to configure the throttling rate programatically.  This means that you can write your own module that automatically determines the desired throttling rate for any response - media or not - which opens up the possibilities for any custom throttling scheme.

The bit-rate throttling support is a key part of the media story comprising Silverlight, Expression encoder, and future media features coming out of the IIS 7.0 team. And, it directly affects your bottom line by saving cold hard cash on bandwidth costs, which can get fairly large for media-intensive sites.

So, go download the bit-rate throttler and start saving money today (and let me know if you are - I'd love to hear your success stories).

Thanks,

Mike