@naltimari - Well I have successfully gotten my installation to work with IIS at the root level. I have also left the default Web Access on IIS intact. If you can get IIS to work subsonic you've already done the hardest parts:
1. I created an empty subsonic directory in my C:\inetpub directory.
2. I created a new website in IIS called Subsonic and pointed it to the empty directory in step 1. I told it to utilize my default IPv4 adapter and to use a Fully Qualified Domain Name of "<blah>.dyndns.org" replacing <blah> with my actual dynamic dns FQDN.
3. I setup Tomcat and Subsonic on port 8080 and verified that that all worked correctly. (Look elsewhere for these steps, you'll find them.)
4. When setting up the isapi_redirect.dll, as shown elsewhere, instead of using the default website, I used the Subsonic website in IIS.
5. I verified that subsonic worked in IIS via
http://<blah>.dyndns.org/subsonic/
6. Now to make it the root directory instead of the /subsonic/ directory I went to tomcat and renamed my ROOT directory in the tomcat webapps folder 'ROOT original' to preserve it as a backup.
7. In the same directory I changed my subsonic folder to 'ROOT' and subsonic.war to 'ROOT.war'. I restarted Tomcat.
8. I then verified that subsonic was my root java application in tomcat by browsing to
http://localhost:8080/
9. Having verified that, I made the following change to my uriworkermap.properties file. I changed "/subsonic/*=wlb" to "/*=wlb" and restarted IIS.
10. I verified that subsonic was now available at
http://<blah>.dyndns.org
Presto! I also have an internal domain I use, in order to add that to the subsonic web site all I had to do was add another binding for subsonic.<internal.domain> and create an entry for it in the DNS table. Because I did not mess with the default web site any other request to the server other than <blah>.dyndns.org or subsonic.<internal.domain> will be served as normal.
@trickydick - I then dug around to find your issue with caching and indeed I have found it. I only have this issue when I'm streaming files that need to be transcoded through IIS. Files that need to be transcoded work just fine through the tomcat interface on port 8080. Additionally, files that dont need transcoding play just fine through IIS. this leads me to think that there is something going on with the isapi_redirect.dll where it is waiting to get the final chunks of stdout from lame (via tomcat). I have seen on the tomcat website that there is a compiler option for chunking. I think this may be our answer. Thoughts?