Stefan Caunter

When you uninstall 1.1 version, it deletes all of your server level redirects. Not fun if you have a lot of them. Here is an alternative to recreating them all in the GUI.
First, open c:\windows\system32\inetsrv\config\applicationhost.config and copy the entire <rewrite> container to another file.
The container starts with <validation />
<rewrite>
<globalRules>
And you will put it back under <validation /> after the upgrade nukes everything.
Grab everything down to </globalRules></rewrite> and save it, I used rewrite.txt
Now you are ready to uninstall 1.1. This is done in programs and features in control panel. You need to reboot after the uninstall.
When you are back up, get URW2.0 from iis.net.
Go back to your AHC file, open it, and scroll to the validation tag. No rewrite rules. No problem. Paste in your saved rules from rewrite.txt and save out.
You need to restart the web server. Check that your app pools are all alive.
If you get errors, you likely have duplicate hostname entries in the ruleset. Version 1.1 tolerated this, version 2.0 does not, and this will break your web server. Check the line in the error, and go back to AHC and remove the duplicate entries.
URL Rewriter 2.0 is an improvement over the RC version. High traffic servers still show memory leak. There is a registry entry that may help this, at the expense of CPU. Balancing this is something we haven’t tried. Solution is to recycle the app pool (32 bit) at a Private Bytes threshold that keeps it from getting unhealthy – 1.5GB for us.

Somewhat different issue now, more handles seen, but same result, memory usage increasing to the 32bit limit.

Plenty of fun the last couple of weeks with URL Rewrite. We’ve started using rewrite rules more in the past couple of months, and seen memory use go up. Like it’s eating it. w3wp.exe was getting to 3GB, and eventually exceeding 32 bit space. We adjusted IIS so the app pool recycled at 10 hours, or if the app pool private bytes size reached 2GB. Decent workaround, but we’re leaking memory like never before.
Conversations with an IIS engineer and a fair amount of tracing of the memory image and the processes led us to URL rewrite as the culprit.
Microsoft is not versioning very well with URL rewrite. The 1.1 you have may not be the latest 1.1! We found that 1.1 was actually 7.x and that we needed to “upgrade” to a later 1.1. Same thing though, memory leak. Version 2.0, an RC, was the next recommendation.
We found that uninstalling 1.1 removed all server level rewrite rules from applicationHost.config – fun! We always have a backup of that file though. You also need to reboot if you uninstall 1.1. Upgrading to 2.0 and restoring a previously working applicationHost.config breaks your server. 1.1 server level rules are incompatible – IIS7 complains about addservervariables not having a section. Whatever. I recreated the rules in the 2.0 interface from another server in the farm. Really wish MS had documented this difficulty, or at least warned that upgrading to 2.0 nukes your global rules.
Last, but not least, we learned also that server level rules actually run in every w3wp.exe process. At the time of this writing, we see that memory usage is much better with URL Rewrite 2.0. The folks on the URL Rewrite team seemed to acknowledge that memory leaks have been a problem for the module, and that itself meant that we were going to have to look at rolling out an upgrade across all production machines. Being able to copy out applicationHost.config to each server in a load balance pool is essential in this case. I don’t even want to think about doing hundreds of rewrite rules that are running on 1.1 and putting them onto 2.0. Not yet anyway.

So:  rewrite.dll, in C:\Windows\System32\inetsrv

Release  1.1 : Product Version 7.1.470.0 from April 15, 2009 – size 137KB

Release Candidate 2.0: Product Version 7.1.659.0 from November 4, 2009 – size 377KB