IIS 7.0 introduced a completely new delegated and distributed configuration system. This offers a number of benefits, which are welcome changes for us web administrators, but there are some gotchas.
In fact, I would say that the distributed configuration system is one of the top areas of frustration and friction in IIS 7.x. A solid understand of the configuration system helps position the web administrator to avoid the gotchas, and also makes it easier to understand the reasons and benefits hidden between these supposed concerns.
This is week 17 of a 52 week series on various web administration related tasks. Past and future videos can be found here.
Having problems viewing on your mobile device? Click here instead.
Microsoft’s Internet Information Services (IIS) web platform is extremely robust, and one of the neat features is overlapping application pools.
In today’s video I cover the theory behind overlapping app pools, forcibly killing the w3wp.exe worker process and on-demand starting of app pools. This is helpful in knowing the impact of recycling an application pool, and what measures you can take when troubleshooting high CPU, high memory or other issues in your IIS environment.
This is week 16 of a 52 week series on various web administration related tasks. Past and future videos can be found here.
Having problems viewing on your mobile device? Click here instead.
Virtual Directories and applications are useful special folder types in IIS. Yet it’s easy to be confused between them.
Today I cover the differences between vDirs and Applications as I cover the 4 different IIS folder types.
This is week 15 of a 52 week series on various web administration related tasks. Past and future videos can be found here.
Having problems viewing on your mobile device? Click here instead.
As you may be guessing already, I’m a big fan of URL Rewrite for IIS. Today I cover Outbound rules, providing demos on changing the content in-flight and adding Server Variables (HTTP headers) for the browser.
Also, in the 2nd half of the video I demo ServerNameVariable a URL Rewrite Provider add-on for making the server name available. See this blog post for further details and a download link.
This is week 14 of a 52 week series on various web administration related tasks. Past and future videos can be found here.
Having problems viewing on your mobile device? Click here instead.
IIS URL Rewrite is a powerful tool that I’ve grown quite fond of. One variable that URL Rewrite doesn’t have, which I wish it did, is the Server Name (Machine Name, Computer Name, whatever you want to call it). The server name isn’t a normal HTTP server variable. So, I wrote a simple provider to take care of that.
What I want to be able to do is provide the ServerName in an x-header variable so that Fiddler or Firebug can see the server name. This is especially useful in a web farm situation where I want to see which node serves up a particular page or image.
Note: Last week I released SiteServerDetails, a component to provide site and server details as an HTTP Module. Together these add valuable troubleshooting add-ons to a web farm.
This blog post makes the URL Rewrite Provider—called ServerNameVariable—available for anyone else that wants to use it. The code is very simple, based on this blog post.
Before I explain the install and usage, I must point out the caveats, which may affect your decision on how you use it:
- This supports ASP.NET v2.0 and greater. If you still have a v1.1 site, this will cause it to break.
- If you use it with an outbound URL Rewrite rule, unfortunately it ‘fails closed’. In other words, if it fails for any reason, it will break all page requests.
- I’ll save you the effort of testing this. If you have an ASP.NET v1.1 site and you want a global level URL Rewrite rule, you’re out of luck. The conditions are run ‘after’ the provider check fails.
- There is some performance overhead to add a X-Header to every page request. It’s very small, but worth mentioning.
So, why use this then? Well, it’s not quite as bad as all that. If you don’t have a v1.1 site, then you can register this at the server level. It will either work or fail when you set it up, it is very doubtful that it will fail over time. In other words, once it’s working it shouldn’t break unless you add another web farm node and you forget to install it there.
This is great for troubleshooting a single site. If you create a site rule then it won’t affect other sites. You can enable or disable it easily so it can be used in troubleshooting situations rather than leaving it on all the time.
To install, download from the link below, extract and run install.bat. That will add to the GAC and register the provider in IIS. So far so good. This is done without any impact to the server.
The install won’t create the outbound rule. That I left for you to do manually because of the caveats mentioned above.
The install takes care of registering it, so to use it, simply call it like you would any other server variable using {ServerNameVariable:}. Notice the required colon (:). That’s necessary when calling a provider.
If you prefer to see this in a video format, here’s a video on URL Rewrite outbound rules, and in the 2nd half of the video I show the install and usage for ServerNameVariable.
The following image shows everything that is required to add an HTTP header called X-Machine-Name to every outgoing request. Of course you can filter by page type or whatever else you need. This rule will add to all page requests.
The key elements are:
- Matching scope = “Server Variable”
- Variable name = “RESPONSE_X_Machine_Name”. Note that underscores are changed to dashes in outbound rules, and it must start with RESPONSE_.
- Pattern = “.*”
- Action Type = “Rewrite”
- Action Value = “{ServerNameVariable:}”
Here’s the generated config:
<outboundRules>
<rule name="Set Custom Header" enabled="true">
<match serverVariable="RESPONSE_X_Machine_Name" pattern=".*" />
<action type="Rewrite" value="{ServerNameVariable:}" />
</rule>
</outboundRules>
Download: http://weblogs.asp.net/blogs/owscott/servernamevariable.zip
Source code: http://weblogs.asp.net/blogs/owscott/servernamevariable_Source.zip