All posts tagged troubleshoot

I’ve been running FTP Services on Windows Servers since the days of Windows NT.  Personally, I prefer a 3rd party product such as RhinoSoft’s ServU or Ipswitch’s WS_FTP Server.  But “free” is a good price, and I’ve setup plenty of built-in FTP systems over the years.

However, I just had the dubious honor of installing FTP on a Windows 2008 Server for the first time.  Like all things Microsoft, it was a great study in how to over-complicate the simplest, most inane thing!  As such, I thought I’d draft a post to list some quick troubleshooting tips to help save someone else a few minutes/hours of frustration.  There’s no rocket science here, just a few helpful hints.

One of the big issues with configuring FTP is that there’s very little in the way of feedback (error messages, etc.) when it’s not configured properly.  It just simply doesn’t work, and there are a zillion possible reasons why…

Obviously, the first thing is to make sure your firewall is flowing through traffic on port 21 for the target IP address.

Next, you need to make sure that FTP services are actually installed!  In my case, my default server install did NOT have FTP services installed.  I had to setup the roles and such to get the WWW services (and IIS) installed, which includes FTP under its wing.  So make sure you do have FTP properly installed.

The next helpful hint:  you have to create a site!  I know this sounds dumb in hindsight, but in the past when you installed WWW and FTP services you got a basic default site.  I like to run FTP from a command-line to just see the welcome banner to know I’m talking end-to-end and reaching the server, to eliminate firewall issues and the like.  Even if you hadn’t configured user access yet, you could still at least hit it and see that you were “talking” to it (getting the welcome banner, etc.)   But in Windows 2008 Server R2 no such luck.  Even with the FTP services running, nothing happens…  it’s dead, and you don’t know why.   You have to create an FTP site inside of IIS first.  Then magically, you can now connect to FTP services and get the welcome banner!

At that point, I was able to get a login banner but not actually login.  To setup logins, you have to hit two different settings icons in IIS.  First, you need to hit the “FTP Authentication” icon to choose “anonymous” or “basic” access.  By default they’re both OFF so nobody can get access, which does make sense from a security standpoint.  Anonymous is self-explanatory, and not what I wanted — I wanted to require authentication to get in.  “Basic” is unclear in my opinion, but is what I wanted.  Essentially, “not anonymous”.  Genius.  So enable “Basic Authentication”.  But that just enables the authentication types you want to allow — still nothing happens yet.

Next, you have to go to the icon next to that one, called “FTP Authorization Rules”.  Because again, by default NOBODY has access.  This is where you choose which users have access.  The dialogs are a little bit cumbersome, in true Microsoft style, but relatively straight forward.  Enter a username or class of user (“Admins”, etc.) and the type of access you want to allot (read, write or both).

At that point, I was finally able to connect and authenticate.

As I mentioned before, in hindsight this all makes sense and I perfectly well understand how and why it’s setup the way it is.  It’s just not overly clear, and is a departure from past setup processes, so I thought I’d share the experience and hopefully save someone a few grey hairs… I’ve got plenty to go around already.

“Hi.  I think our web site is down.”

Nothing can ruin a day faster than those words.  It can send an afternoon into the can in three seconds flat.

On the positive side, more often than not it’s really not a web site / web server problem.  On the negative side, that really doesn’t matter — you still need to go through all of the requisite steps to properly diagnose and isolate the actual problem.

When faced with a generic “Is the web site is down?” query, the best course of action is to quickly check a few of the basic fundamentals to rule out 90% of the most common and most obvious issues, continuing to peel back the onion (so to speak) through each subsequent layer.

First, I obviously check the web site myself, from my own machine or phone.  If I can reach it and make it respond to dynamic requests (that is to say, hit pages and see them load, especially if database-driven), then that proves that the web site is alive and responsive, and I’m not just seeing older pages cached from hours or days before. In that case we’re usually done — the issue is the client’s own Internet connectivity at their location, or with their immediate upstream Internet provider.  Maybe their cable modem provider (etc.) is having a glitch, and so forth.

The more savvy clients will have thought of this already and tried from a separate Internet provider, whether calling someone they know (“hey Martha, can you reach my site?”) or checking from their smartphone over a 3G cell provider that provides a completely diverse route to the web site than their desktop computer would be taking.

So if the site is in fact unreachable, then we move on to checking the basic network connectivity problems…

Read more…