Tech Line

FTP Frustration

Troubleshooting FTP -- where to look.

Chris, I just set up FTP with IIS on a stand-alone Windows 2003 server. I cannot connect to it and, to be honest, I don’t even know where to start. This is my first time setting up FTP and I’m basically stuck. Can you help?
— Scott

Tech Help—Just An
E-Mail Away

Got a Windows, Exchange or virtualization question or need troubleshooting help? Or maybe you want a better explanation than provided in the manuals? Describe your dilemma in an e-mail to the MCPmag.com editors at mailto:editor@mcpmag.com; the best questions get answered in this column and garner the questioner with a nifty MCPmag.com baseball-style cap.

When you send your questions, please include your full first and last name, location, certifications (if any) with your message. (If you prefer to remain anonymous, specify this in your message, but submit the requested information for verification purposes.)

Scott, I don’t have a lot of detail here, so let me try and cover the big picture. Prior to users knowing about FTP servers, most disgruntled users used to think that FTP stood for "F#&% This Place!" So if you’re frustrated, you probably have plenty of people who feel the same way around you.

My first advice is to cut the problem in half. See if you can connect to the FTP server from a host on the same subnet as the FTP server. This will help to determine if the problem is related to the FTP server itself or with your external firewall or router.

A simple way to run this test is to connect to the FTP server from a host on the same subnet as the FTP server using the FTP command-line utility. Assuming your server is named ftp.company.com, you would run this command: ftp ftp.company.com. A connection should be established and you should be prompted for a user name and password. If you cannot connect from the same subnet as the FTP server, then you know the problem lies between the internal host and the FTP server. At this point, you should look to make sure that FTP service requests are not being blocked by a software firewall such as the Windows firewall.

If the Windows firewall is causing the problem, I recommend that you enable firewall logging to confirm this. You can do this by following these steps:

  1. Click Start | Control Panel | Windows Firewall.
  2. In the Windows Firewall dialog box, click the Advanced tab and then click Settings button in the Security Logging portion of the window.
  3. In the Log Settings window under Logging Options, check the "Log dropped packets" checkbox. Then click OK. I prefer to always log dropped packets, as it will let you troubleshoot firewall issues quickly in the future.
  4. 1.While you’re at it, it’s a good time to make sure that FTP access is enabled. Click on the Exceptions tab and ensure that an exception exists for FTP. If not, you will need to click the Add Port button and create an exception for FTP (minimum = TCP port 21).
  5. Click OK to close the Windows Firewall dialog box.

With logging enabled, you can check the C:\Windows\ pfirewall.log file to see packets that were blocked by the firewall. So, to test for blocked FTP connections, just attempt to make an FTP connection from a host to the server and then view the firewall log after the connection fails.

Remember, if you can connect internally to the FTP server, then the problem lies with your external connection. This requires you to ensure that the firewall’s access lists and/or port translation is configured to allow the FTP traffic through. By configuring and viewing logs on your perimeter firewall, you can also determine if the firewall is blocking external access.

OK, so we've talked about the general networking and firewall issues, but we've also ignored the FTP server application itself. At the server, the easiest way to validate that the server is actively listening for FTP connections is by running the command netstat -a.

With the server actively listening for FTP, you should see output similar to this:

Active Connections

  Proto  Local Address   Foreign Address    State
  TCP    server1:ftp     server1:0          LISTENING

If the system is not actively listening for FTP connections, then you'll want to ensure that the "FTP Publishing Server" (MSFtpsvc) is running. In your case, this service should be set to Automatic.

For troubleshooting the FTP server application itself, connection logging is invaluable. You can enable connection logging by going to the properties of your FTP site in IIS Manager and checking the Enable Logging checkbox. If you click the Properties button in the FTP Site Properties window and then click the Advanced tab, you can get very specific on the type of traffic that is logged. You can view the FTP log file in the C:\WINDOWS\system32\LogFiles folder, by default. For me, the FTP logs is often the first place I check when trying to diagnose an FTP connection problem.

While I’ve tried to look at the big picture of FTP and the general areas of troubleshooting, there are literally dozens of potential problems that lie between an FTP client and server. Microsoft wrote a very good KnowledgeBase article, 323358, entitled, "How to Troubleshoot a Web Server in Windows Server 2003," that should help you with other specific FTP server-related problems.

Again, to me the log files (external firewall, software firewall, FTP server), along with the Windows Event Viewer, are the first places that I start, as they can usually give me specific information on a connection error. I hope that the FTP troubleshooting doesn’t have you too frustrated. If it does, shout "FTP" a few times. That should make you feel better.

About the Author

Chris Wolf is a Microsoft MVP for Windows --Virtual Machine and is a MCSE, MCT, and CCNA. He's a Senior Analyst for Burton Group who specializes in the areas of virtualization solutions, high availability, storage and enterprise management. Chris is the author of Virtualization: From the Desktop to the Enterprise (Apress), Troubleshooting Microsoft Technologies (Addison Wesley), and a contributor to the Windows Server 2003 Deployment Kit (Microsoft Press).learningstore-20/">Troubleshooting Microsoft Technologies (Addison Wesley) and a contributor to the Windows Server 2003 Deployment Kit (Microsoft Press).

comments powered by Disqus
Most   Popular

SharePoint Watch

Sign up for our newsletter.

Terms and Privacy Policy consent

I agree to this site's Privacy Policy.