Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I apologize if this is too broad or belongs on Super User (please vote to move if it does).

I'm in the process of creating requirements for an internal PHP web server to submit to our architecture team and would like to get some insight whether to use a Windows or *nix platform and what applications would be required. The server will host a small PHP application that will be connecting to SQL Server. The application will need to send mail. We would also like to incorporate a FTP server to allow files to be dropped in.

From what I've read regarding a Windows platform using IIS, it seems as though IIS would only be advantageous if using a .NET or ASP application. Does IIS have mail functionality? Or how is mail traditionally configured (esp. on *nix)? Also, does IIS have directory configuration functionality like Apache does with .htaccess?

For a Windows based solution;

  1. IIS (comes with FTP)

  2. Apache (has mod_ftp module)

For a *nix based solution;

  1. Apache
share|improve this question
up vote 1 down vote accepted

The beauty here is that both platforms and servers would serve your needs. IIS runs PHP very well actually and at one point in time actually ran it faster than Apache, but that is dated information.

All of your other questions can be easily answered with "Yes".

It sounds like you are more familiar with Apache's abilities than IIS's. IIS also ships with an SMTP agent/server/client that can do multiple actions with mail to be sent and can deliver it as needed.

While IIS also runs ASP.NET natively they also now consider PHP to be a native extension thanks to the FastCGI component. You can learn more about architecture and design suggestions here:

Either way, both platforms will serve your needs and both web servers will work as well. It really boils down to your teams skill sets and comfort levels with different tech. The rest is simply research leg work on your part.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.