Running an FTP Server on IIS 5.0

FTP is the protocol used for copying files to and from remote computer systems using TCP/IP. It is the transport mechanism that many (if not most) Internet content management solutions use. This protocol lets users use FTP commands (or programs) to work with files, such as listing files and directories on a remote system. Windows 2000 installs a single FTP server by default when it installs Microsoft IIS. IIS 5.0 facilitates having many FTP servers on one machine.

The default FTP server that IIS 5.0 installs is configured and ready to go with anonymous access immediately after installation. If your network has a name resolution system (typically DNS), visitors can type ftp:// and the DNS name in the address bar of their browsers to reach your site (e.g., ftp://ftp.microsoft.com). If your network doesn't have a DNS-like system, visitors must type ftp:// and your server's numerical IP address. Command-line users can still use a standalone command-line FTP program that's available on many platforms and OSs.

Anonymous FTP access is an authentication mechanism that is identical to Anonymous authentication for the IIS 5.0 Web server. Users can connect to your FTP server without providing usernames and passwords (except for a username of Anonymous and a password of their email address) because IIS uses IUSR_computername to provide anonymous access. You can specify a different account for anonymous access. You can also restrict access to resources using NTFS permissions. Note that even if you enable Basic authentication, Anonymous authentication takes precedence, and IIS 5.0's FTP server will use it first.

Here are three "hot tips" about FTP site feature configurations that I found in the MSDN Library:

After a user logs on, IIS places the authenticated client in the virtual FTP site of the same name. The client has full control over directory content and can upload files. An anonymous user who logs on can read the files but will have no control over them and won't be able to browse outside the virtual FTP directory.

One of the main drawbacks of using FTP as a content management solution on secured sites is that the transfer loses file permissions (ACLs) and attributes. If you secure a Web page by putting ACLs on it on your development or staging server and use FTP to copy that page to a production server, you lose the file permissions. If you use Visual SourceSafe (VSS) on your development server and you author a page and check it in, VSS sets a read-only attribute on the file. If you use FTP to transfer that file to a production server, you lose that read-only attribute.

Microsoft Content Replication System, which shipped in Microsoft Site Server 3.0 and now ships in Microsoft Application Center Server 2000, overcomes the problem. It retains file permissions and attributes when copying files. CRS has a file transfer mechanism very similar to FTP's, and because of its superior capabilities, Microsoft uses it extensively internally—and has for years—in content management solutions.