Robert McMurray

Many years ago I wrote Microsoft KB article 203064 about using Server-Side-Include (SSI) files with IIS 4 and IIS 5, but that KB has long since vanished from Microsoft's support website because it was never updated for IIS 6 or IIS 7. I eventually turned the information from that KB article into a blog post, but that being said, I still see questions about SSI showing up in the IIS forums every once in a while. There was a great deal of useful information in that KB article about general SSI syntax and several practical examples for SSI directives, so I thought that it would make a good blog post if I updated the information from that KB for later versions of IIS.

I love BlogEngine.NET, and I love my Windows Phone 7 mobile phone, so it goes without saying that I would want the two technologies to work together. I'm currently using BlogEngine.NET 1.6.1, but Windows Phone 7 is not supported by default. That being said, it's really easy to add support for Windows Phone 7 by modifying your BlogEngine.NET settings. To do so, open your Web.config file and locate the following section:

I ran into an interesting situation recently where a customer was using F5's BIG-IP for SSL offloading with their web farm and they were having problems with WebDAV. Here's the details of the scenario: BIG-IP adds a proprietary FRONT-END-HTTPS: ON header to requests, and that header is ignored by IIS 7 because it's proprietary to BIG-IP. This is expected behavior, but it presented an interesting problem from a WebDAV perspective - the responses to PROPFIND requests contain XML with URLs. Since BIG-IP is performing SSL offloading, the requests use HTTPS to BIG-IP, then HTTP from BIG-IP to IIS, so the URLs in the XML of a PROPFIND response are listed using HTTP instead of HTTPS. So when a WebDAV client tries to access any of the URLs from the PROPFIND response, it's using the non-secure URL instead of the secure URL.

Several months ago I wrote a blog that was titled "Fun with Search Engines (Bing versus [other])," where I described how I had used the Bing Search API and Microsoft's Internet Security and Acceleration (ISA) Server 2006 to trick users on my home network into using a website that looked and acted like a Big Search Engine That's Not Bing (BSETNB) even though it was secretly using Bing under the hood. If you had read my earlier blog you would have known that I did this as a test to see if anyone would detect any differences, and oddly enough no one actually noticed.

I have to admit right up front that I'm not a PowerShell expert. But having said that, I had a great question a few days ago from Chris Morrow at MaximumASP - Chris asked how I could use PowerShell to modify the Configuration Redirection settings for IIS 7. I had only written PowerShell scripts that accessed settings in the applicationHost.config file, so Chris' question piqued my curiosity. After a while my curiosity gave way to obsession when my first couple of attempts weren't successful, but I'll spare you the details and stick to describing what worked. ;-]

Someone asked me an interesting question the other day, "How do I detect if any users are leeching my FTP site?" That's a great question, and it warrants some explanation and a little LogParser code.

We recently hosted a group of customers from a large hosting company here at Microsoft, and as the meeting was getting started everyone in the room was introducing themselves to the other attendees. As I was shaking hands with one of our visitors, I introduced myself by name and he had a brief moment of recognition, then he asked, "Wait a minute - are you the guy that's trying to drive a stake through the heart of the FrontPage Server Extensions?" I laughed and answered, "Well, I wouldn't put it that way, but yes - that's me." He ecstatically replied "Thank you!" and proceeded to give me a high five, then he continued the discussion by explaining how much he hated the FrontPage Server Extensions (FPSE).

Over the past few months we've been working on an update to the IIS Configuration Reference, which is on IIS.net at the following URL: