One of the new and long awaited features in IIS 7 is support for FTPS or FTP over SSL.  By default all FTP data is transfered in clear text, including the user name and password.  From a security point of view you can see this is a bad thing.  FTPS to the rescue!  Before you begin you will need to download and install FTP for IIS7 and you can do so here:

• FTP for IIS 7 on Windows Server 2008 x86
• FTP for IIS 7 on Windows Server 2008 x64

The first step is to create the certificate.  You have two options, create a certificate request to process with a 3rd party SSL cert provider and then complete the request by importing the supplied cert, or creating a self signed certificate.  For production systems ALWAYS use a 3rd party cert from a trusted root.  For this setup we will use a self signed certificate so we will start by creating one.

Click on Create Self Signed Certificate called My FTP Certificate…

Next click on Default Web Site and then double click on FTP SSL Settings.  Select your SSL certificate from the list and then choose Allow SSL Connections. Click Apply and we are almost done!

We can test it out by connecting to the FTP server with the following command:

ftps localhost

If all goes well we will be connected.  Now we enable SSL with the following command:

SSL on (enter)

bye (enter)

You will be disconnected but you can see that SSL for Commands and SSL for Data is set to on.

Now that SSL is enabled we have the option to force it by choosing Require SSL Connections.

Again click apply and if we try and login with:

ftp localhost

We will see the error message that the “SSL policy requires SSL for control channel”.

If you want to try this out for yourself you can via the TechNet Virtual Labs.

For more information see:

TechNet Virtual Lab: Administering the IIS 7 File Transfer Protocol (FTP) Server

Note: this content originally from http://mygreenpaste.blogspot.com. If you are reading it from some other site, please take the time to visit My Green Paste, Inc. Thank you.

Ran into the following while configuring IIS 6 on a new system. Not sure if I need to be concerned...

We previously covered the final release of the IIS FastCGI module, jointly developed between Microsoft and Zend… But just this week, Microsoft (MSFT: $33.76 -0.50%) announced the availability of the RTM of the IIS FastCGI module.

So what’s going on? We’ve downloaded the current release (which, by the way, is not compatible with the old one, you must uninstall then install the new version) and checked the version number on \Windows\System32\inetsrv\fcgiext.dll - it came out to be 6.1.36.1.

By contrast, the version we downloaded and installed a month ago (which seems to have been dubbed the Go Live release) was checked and found to be 7.0.6001.16606.

Obviously the Go Live release was using the numbering from the Microsoft Windows Server 2008 releases, but it’s got us confused.

We’ve been working on moving to a new server all week, and we’ve just finished the transition. Best of all, we’ve switched to the new servers without any downtime in-between. Our new server is a 1.86 GHz Core 2 Duo and with 3GB of DDR2 RAM - all thanks to the awesome guys and gals at Lunarpages, the best host there is.

A lot of work has gone into this transition in hopes of raising the performance - and more importantly, the reliability - of our server. In the past year (since we first started our hosting with LP), we’ve gone from several million hits a month to dozens of millions, and our old server took quite a hit. To that end, we’ve focused on deploying lightweight and highly-optimized code all around; hopefully there will be no more un-expected downtime… ever.

Our current software setup is very complicated, but hopefully it’ll take us all the way to 0.00 minutes of downtime - that’s our goal! We have multiple application servers and programs running in the background each doing what they best - instead of the traditional have-the-web-server-do-it-all way. At the moment, we currently have a software stack comprising of a tightly-knit mesh of these products:

Congratulations are in order for Microsoft’s IIS development team - today they’ve just announced the public availability of the final version of the IIS-FastCGI ISAPI Extension - a long-awaited and much-improved way of running just about any open-source scripting engine on IIS, safely and quickly.

This FastCGI module for IIS 5.1, 6, and 7 (with Windows Vista and Server 2008) have been in the works for quite a while now, and we’ve been using them since the first beta release - they’re good. While the biggest benefit will be seen in using FastCGI w/ IIS7 to take advantage of the new kernel-mode caching, it’s still a huge improvement over the old way of running scripting engines for languages like PHP on Windows.

The Problem: Most open-source scripting engines like PHP and Ruby on Rails were initially developed on/for the *nix world. On Unix-based platforms, the easiest way of creating multi-threaded applications is just to run the same app twice or more (The CGI model). On Windows, that doesn’t work out so well, because it takes a lot more resources to create another process. So these engines released Windows-specific single-process multi-threaded engines; the only problem was, they weren’t stable. Too many race conditions in some very non-thread-safe code wreaked havoc on many Windows systems, with the PHP developers themselves giving “Stability on IIS” the lowest level of concern.

For all the Windows-bound PHP users out there, consider yourselves warned: even if you’re running the (supposedly) thread-safe PHP Win32 binary redistribution, you’re still susceptible to PHP Access Violation Errors, race problems, heap corruption, and much worse if you use the popular eAccelerator opcode-caching extension.

We did our testing with the binaries compiled by SiteBuddy using the latest versions of both PHP and eAccelerator. Almost immediately after initiating a stress test on our test servers we experienced the dreaded “PHP Access Violation” error - which brings down the entire IIS Worker Process to its heels.