Yesterday I finally started my RC1 Server 2008 installation to replace the older Beta 3 setup. However, one piece of software refuses to install - Cygwin:

The funny part - it worked just nicely in Beta 3 (I need it for WebSVN, which now obviously is offline). But at least it seems that I am not alone with this issue: Installation problem with Windows Server 2008

In my previous post FastCGI in IIS7 I mentioned that I am running WebSVN on this box to give FastCGI a real-world test run. Today, I upgraded to v2.0 of WebSVN. They sure do ship a good-looking template this time around:

The RSS functionality is enabled too in this version (I was running code directly from their repository last time around...). I have to say that WebSVN turned into a must-have tool for anyone using Subversion.

Link to WebSVN on iis7.chrison.net (feel free to play around)

A default install of Windows Server 2003 ships with a locked-down Internet Explorer, in a so-called enhanced security configuration. Getting rid of it was done via configuring the Windows components. Not so on Windows Server 2008. At first of course I looked in all the wrong places (after all who reads a text they "know"?), until I found it in Server Manager:

You can turn it on / off separately for administrator or users:

Why did I turn it off? Because when it is on, you cannot view IIS7 FREB log files - the XSL has code in it that won't run in any browser but IE. At least at Beta 3 of Longhorn, that is.

Tuesday June 19th I will be doing two sessions on IIS7 - administration and programmability.

Today, I completed the setup for my IIS7 FTP site - enabling SSL for secure transfer. It took me a little while longer than expected, mostly because I was looking for passive mode transfer settings in the wrong place at first. To save others from repeating my mistakes, here is a quick step-by-step how to get up and running:

First, we need to configure passive transfers (PASV). This is configured at the server level

via the (in my opinion) not-so-intuitive "FTP Firewall Support":

This shows the following panel (I have opened the range 2200 to 2205):

This panel is also available at the site level (that's where I got stuck), but it won't be of any use.

Although the FTP server is configured for passive, the Windows firewall isn't (and remember, it is on by default!). You need to create an inbound rule for the passive ports like so:

Now we are ready to enable secure FTP - and this is rather simple. Go to your FTP site, and check that the FTP SSL Settings are configured as follows (you could also force SSL connections to make sure no one unintentionally connects with their pants down):

You are basically all set. Give your setup a try using eg FileZilla. Create a new site in Site Manager, and set the server type to "FTP over SSL (explicit encryption)":

The last step is to make sure you are using passive mode (in FileZilla, this is part of Advanced):

If you didn't miss a step, you now should be able to securely connect to your FTP site.

Before going on holidays last week I decided to put a Longhorn Beta 3 box live on the Internet. It doesn't run a lot of things just yet (except for trials of the all-new FTP server), but today I decided to take the plunge and try FastCGI (see Using FastCGI to host PHP applications on IIS7).

An application I wanted to test-drive for a long time is WebSVN. The UI looks like this:

It is PHP-based, needs Cygwin-based tools, and is quite useful for browsing Subversion repositories. After downloading the latest code from the WebSVN repository, I was able to get up and running in about half an hour (that includes failing with WebSVN RC4, installing Cygwin, etc). You can check it out at http://iis7.chrison.net/websvn/index.php

I'll add more applications to this box over the coming days and weeks, to see what works and what doesn't for the mix of technologies I am using.

Oh, and it seems that I am the first European site registered at IIS7 On Tour:

Bill Staples put together a post on what's new in IIS7 Beta 3. He also talks about the all-new IIS7 FTP server (which I knew about for a long time - I had hoped Beta 3 would be available for my MSDN Briefing in Vienna last month, but no such luck). Also, he mentions the GoLive! license for IIS7.

This Q&A item is part of the current MSDN magazine's Security Brief's column by Keith Brown. I am pretty sure that this problem will rear its head sooner or later on every developers machine, that's why I am 'pinning' the link in my blog for my own reference too.

Now, that scalability documents list is way cool. A lot good stuff on IIS performance, and especially real-world debugging of Web applications.

Be sure to check out IIS.net, the Web site dedicated to IIS7. There you will find forums, whitepapers, webcasts, HOL virtual labs, walkthroughs, FAQs and more.

Yesterday after my talk at MS' Big>Days 2006 in Vienna I was asked how to recycle an IIS app pool from within an application / script / code. I knew I had seen it somewhere before, so I promised to post the information in my blog as soon as I had dug it up.

There are actually a few others that have posted that information before, for example on the aspitalia.com blogs - Riciclare un application pool di IIS 6 da codice C#. It does exactly what the post title implies: recycling an application pool with C#. This approach uses ADSI (aka System.DirectoryServices) to do the bidding, and I have the non-ASP.NET bound version here:

using System.DirectoryServices;

...

public void RecycleAppPool(string machine, string appPoolName)
{
string path = "IIS://" + machine + "/W3SVC/AppPools/" + appPoolName;

DirectoryEntry w3svc = new DirectoryEntry(path);
w3svc.Invoke("Recycle", null);
}

So, now the question arises - how do I know the names of the app pools? One way is to enumerate all the existing application pools on a box - the blog post Control the Application Pool shows how to pull it off using WMI.

Finally, I went to the authoritative source, Chris Adams blog. He has a post up titled Recycling Application Pools using WMI in IIS 6.0, so this is along the lines of the previous one. He has samples in VBScript as well as C# online. He also shows a quick way (end of the post) how to find out which app pool is servicing which IIS Web application.

I think this should cover the topic nicely Also looking forward to how easy recycling app pools will be in IIS7.

There is one feature coming with IIS 7 (http.sys, as such it is more an OS feature) that I have been waiting for a long time: being able to see what's in the kernel cache! The key to this new supercool feature is the netsh command:

C:\Users\Administrator>netsh http show cachestate ?

Usage: show cachestate [[url=]<string>]

Parameters:

    Tag       Value
    url   -   Fully qualified URL. If unspecified, implies all
              URLs. The URL could also be a prefix to registered URLs

Remarks: This command lists all resources and their associated properties
         that are cached in HTTP response cache or displays a single
         resource and its associated properties.

Examples:
      show cachestate url=http://www.myhost.com:80/myresource
      show cachestate

Some information can be obtained in the article New Networking Features in Windows Server "Longhorn" and Windows Vista (you can even flush the cache), and here is how it works if you browse to the default Web site of IIS 7:

C:\Users\Administrator>netsh http show cachestate http://localhost

Snapshot of HTTP response cache:
--------------------------------

URL: http://localhost:80/pagerror.gif
    Status code: 200
    HTTP verb: GET
    Cache policy type: User invalidates
    Creation time: 2006.3.21:23.30.16:0
    Request queue name: DefaultAppPool
    Headers length: 187
    Content length: 2806
    Hit count: 1
    Force disconnect after serving: FALSE

URL: http://localhost:80/iisstart.htm
    Status code: 200
    HTTP verb: GET
    Cache policy type: User invalidates
    Creation time: 2006.3.21:23.30.14:0
    Request queue name: DefaultAppPool
    Headers length: 233
    Content length: 774
    Hit count: 1
    Force disconnect after serving: FALSE

Tracking caching behavior will be so much easier.

IIS 7.0 Beta: Operations Guide
IIS 7.0 Beta: Feature Reference

If you need to find out just what devices are running Web services in your network (aside from the obvious Web servers, this includes nowadays printers, access points and many more), then you should check out httprint. It doesn't rely on server banners or fall for other obfuscation techniques, so it is quite handy to find out just what software is running on that box.

In case you need it too: Configuring SSL Host Headers shows you how to get up and running with one IP, port and certificate but multiple host headers. All you need is a wildcard certificate (learn more here) and some CLI magic because there is no UI for it. Basically, it boils down to (for example):

adsutil.vbs set w3svc/siteid/SecureBindings ":443:host.wildcarddomain.com"

Don't know how this one could slip by me - Windows Server 2003 Service Pack 1 (SP1) shipped a rather important update: you can run SSL in kernel mode (http.sys) instead of user mode. There are restrictions which are detailed here (most B2C SSL sites will do just fine), and the procedure to enable kernel-mode SSL shows how to get up and running in no time. Mostly you are only dealing with the registry key HKLM\System\CurrentControlSet\Services\HTTP\Parameters\EnableKernelSSL.

On Windows Server 2003, this is the default logging directory for the Hypertext Transfer Protocol (HTTP) APIs, better known by the kernel level http.sys driver. Chances are, you don't know that this directory exists, and what is logged there (except that when you are looking right now, you will be surprised how big that directory is!).

When you are using IIS 6.0, all requests are first received by http.sys, and then passed on to IIS - previously, IIS itself was listening for requests. Http.sys is passing on the requests intelligently, which means that certain requests never even reach IIS. For example, invalid URLs are caught:

2006-02-23 19:05:00 172.179.161.165 1422 195.234.231.66 80 HTTP/1.1 GET /serv<script%20language= 400 - URL -

Most oftentimes it is simple connection timeouts, but to get the most out of the (huge) log files, you should be using LogParser anyways.

The reason why I started this blog entry is actually this: if you don't like the HTTPERR log files on your system disk, you can relocate them. The procedure is detailed in the article Error logging in HTTP API, which also dives into the format of the log file, and which kinds of errors are actually logged there.

From the download page: The IIS Diagnostics Toolkit is a combined release of popular tools used by today's IIS users. These tools include tools aimed at resolving problems related to Secure Socket Layer (SSL) issues, permission or security problems, gathering data for your SMTP server included with IIS, as well as the famous Log Parser utility used to sift through hundreds or thousands of log files very quickly.

The toolkit consolidates all the tools into a convienant download and is supplemented by updates every 90-days to ensure that users have the most current diagnostics tools at their fingertips.

Works with IIS 4 thru 6, and is available for x86 and x64.

Next week, I will be in Rosenheim, Germany for the ADC 2005. I'll be teaching the Visual Studio 2005 Team System Hands-on workshop (Tuesday as well as Friday), plus doing two talks during the main conference: IIS 7 and ASP.NET 2.0 Health Monitoring. See you there!

I already have one box (the Shuttle XPC) that is running Windows Server Codename Longhorn Build 5219. Because it wasn't all that much of a hassle when compared to Beta 1 of Windows Vista, I decided to set up Longhorn on my laptop - and try to work with that installation for a week, while I am in Seattle for the MVP & AspInsiders summits. Boy did I end up with an installation marathon...

Lessons learned in this Sunday's "don't try this at home kids" department:

• Don't assume that ATI drivers for your IBM X31 will install on Longhorn. They refuse, making for rather crappy UI performance. By the way, on failing, setup suggests to install a VGA driver first.
• None of the network adapters were found - neither the onboard LAN, nor the onboard WLAN. When you peek into Computer Mangement, it is your guess which of the two "Ethernet Controller" is which.
• Don't only update the driver for one, even if it is the LAN one. Your ISA 2004 client installation will mysteriously fail. After installing drivers for all LAN equipement, it just works.
• Minor annoyance: the OS-provided sound driver produces hisses et al. Not too bad, but annoying if you plan to watch loads of Channel 9 movies. Your guess is correct: the vendor-provided driver refuses to install.
• No standby. That sucks royally.
• You learned about that in my previous post - no .NET 1.1 for you by default.
• Installing VS can be so much fun, especially if MSXML 6.0 refuses to install as part of the default install. Doing it separately works so much better. And the "Locate File" dialog for the VM driver irritated me only for the better part of a minute...
• Before installing the Atlas VSIs, you better start VS at least once. Otherwise the Atlas installation will fail. Only mildly interesting.
• Do I need to mention that Virtual PC networking doesn't work? That one didn't change for the better, which will make me dual boot into XP.

On a different note: default installs of 5219 have a blank password for Administrator. And IIS 7 is installed by default, which really baffled me. I'm so trained to enable features after install that at first I was thinking it was not part of the bits I got...

The day started out with one of those famous spoof videos - this time about a "variation" of Windows error reporting, dubbed WE-SYP (we share your pain). Error reporting tied to a - let's call it - "multimedia" chair. Fun to watch.

Right after that, Bob Muglia showed off what we can expect from Windows Server in the next couple of year. Windows Server 2003 Compute Cluster Solution was demoed together with Excel Services - impressive. TxF (transactional NTFS) wasn't any less exciting, just like the identity solutions - and, of course, IIS 7.0. We got the bits for the latter today. 

Sessions I attended today:

• Windows Communications Foundation ("Indigo"): A Deep Dive into Best Practices Using the Windows Communications Foundation
• ASP.NET: Future Directions for Developing Rich Web Applications with Atlas (Part 2)
• ASP.NET: A Sneak Peek at Future Directions in Web Development and Designer Tools
• Windows Vista & "Longhorn" Server: Under the Hood of the Operating System—System Internals and Your Application
• ASP.NET: Deep Dive into the ObjectDataSource Control

The under the hood session for Longhorn server had one interesting tidbit - they aim to require mandatory signing for kernel mode drivers on x64 platforms - bye bye kernel root kits!

Bradley Millington quite overshot his allocated timeslot for the ObjectDataSource control, but he covered interesting areas: filtering and master details, custom sorting and paging, updates inserts deletes as well as transactions and caching. Seeing realistic examples is a welcome change. A good place for you to start: the Advanced Data Scenarios section of the Quickstarts. (Note: those links point to http://beta.asp.net, and I don't think that Whidbey docs will be up and running there forever, given that "Orcas" starts appearing on the horizon).

Bill Staples is the group program manager on the IIS 7 team. That's Microsoft's Web Server. We spend an hour discovering IIS 7 (the next version of IIS 7). Includes lots of demos. View

At long last some information for the general public (not that it would be news for me).

Looking for great information about Internet Information Services? Then IISWebCastSeries.com is the place to go. Especially interesting should be the Webcast "Recycling IIS 6.0 Applications: The Good, the Bad, and the Ugly" (related blog entry).

The IIS Diagnostics Toolkit is a combined release of popular tools used by today's IIS users. These tools include tools aimed at resolving problems related to Secure Socket Layer (SSL) issues, permission or security problems, gathering data for your SMTP server included with IIS, as well as the famous Log Parser utility used to sift through hundreds or thousands of log files very quickly.

The toolkit consolidates all the tools into a convienant download and is supplemented by updates every 90-days to ensure that users have the most current diagnostics tools at their fingertips. Download for x86