Move from IIS to Apache 2.2.x - How and Why

Ever since Netcraft has started tracking statistics regarding Web server usage, IIS has never beat Apache when it comes to the number of sites using the two servers. In general, the gap between IIS and Apache has been anything but small. Until fairly recently, early 2002 saw Apache's worst day with only a 30% gap between the two products. Today (in mid-2007), however, Apache's share (52.65%) is very slowly eroding in favor of IIS (32.8%), which is bundled with the ubiquitous Windows OS. Of course, these statistics take into consideration all of the free and cheap hosting services that use Apache and don't consider internal use of IIS in many companies, so the "real" values are likely more similar than they appear.

Even so, 20 percent is still a fairly significant gap! There are a number of reasons that your company might consider making the jump from an IIS solution to Apache. I'll quickly explain some of these reasons and then go over some of the ramifications of such a decision and provide some advice for mitigating problems related to this kind of a move.

The focus of this article is on moving from IIS to Apache. As such, I'm not going to spend a lot of time balancing the argument. While I personally consider both IIS and Apache to be worthy products, in this article, I'm not arguing for either option, but letting you know some things you may run into as a part of a transition.

Why change?

IIS is a good Web server, and it's getting better with each new version. Moreover, with each new release, Microsoft improves the security of IIS, making the case for change a little less compelling. And, for some organizations -- particularly those that have a heavy reliance on other Microsoft tools -- a change would simply not make any sense.

Given these facts, why make a jump from a perfectly good Web server to Apache? For those of you that do not have tools -- such as Exchange Outlook Web Access, SharePoint or SQL Server Reporting Service -- that are tightly tied to IIS, are there compelling arguments for making the leap?

The answer: If you have a need to operate in a heterogeneous environment, and have a need to choose a single Web server to use across all platforms, you simply can't beat Apache. The lines have blurred with regard to other issues that used to set Apache apart from IIS, including the security and manageability of the servers.

Another answer: If you need to implement a significant Web service and want to be able to do so with a minimal license cost, consider Apache on Linux for your solution. The direct licensing cost for this solution is exactly zero dollars, unless you choose to make use of a commercial Linux distribution.

For argument's sake, I'm going to assume your organization has made the decision to at least consider moving from IIS to Apache and you want to know what to expect should you decide to begin an actual migration.

Plan for ASP

One significant hindrance to migration efforts from IIS to Apache lies with the issue of dynamic scripting language choice. For most Windows Web environments, ASP or ASP.NET is the language of choice since both are very well-supported and included with IIS. Unfortunately, both are native to Windows, and Microsoft has not moved them outside this playground. However, there are numbers of ways that you can still make the move to the open source Apache/Linux combination (or Apache/Windows, for that matter).

Change to another language

If you only use ASP casually on your site, you can opt to migrate your ASP code to another language, such as PHP. With smaller sites, this is probably best handled manually, but for larger sites, the prospect of converting code could be a major undertaking. However, there are some tools available that can help you with a conversion. For example, asp2php is a free tool that can help you make this leap. While this free tool is only provided to help you make the move (it doesn't do it all, by any means), it can help you avoid some of the tedious task of recoding hundreds of pages of code.

Also, consider the use of a Java-based framework for a site if you decide to take the plunge and migrate to another language. Apache's Tomcat provides you with a free, open source servlet container to help make this change.

If you do decide to make the jump to a new language, remember that it's not the syntax that was difficult to write in the first place, but the logic. Since you already have the logic completely documented in your ASP code, migrating to another language isn't generally as difficult as starting anew.

Keep ASP and still run Apache

One great thing about open source and an open market is that for just about any need, you can find a reasonable solution. In the case of continuing to run ASP code after moving to Apache, there are many solutions available for you to peruse.

The most well-known solution, Chilisoft ASP, is now a product from Sun called Sun Java System Active Server Pages 4.0 and provides ASP support for certain versions of Solaris, Red Hat Enterprise Linux, HP-UX, AIX, and Windows (without IIS, of course). Sun Java System ASP 4.0 supports Apache 1.3 and 2.0 (see below for information about Apache 2.2). Sun's solution also provides ADO support, as well as a full line of ODBC database drivers for use with the product. Among the ODBC database drivers included are drivers that allows Sun's product with work with both SQL Server and Microsoft Access databases. As with anything, a conversion process using this software is probably not going to be 100 percent perfect, and you may need to make some minor code changes to make everything work exactly as you expect; there are some instances -- if you use Visual Basic objects, for example -- in which this solution won't work at all.

Alas, the data sheet for Sun Java System Active Server Pages does not include Apache 2.2 as a supported Web server. Further, Sun Java System Active Server Pages has not been updated in quite some time; and, in a forum, it was indicated that there is no time frame for a future release. This could mean that either Sun just hasn't gotten around to planning an update, or that they bought Chilisoft's product and are no longer updating it.

Another option is to use Apache's mod_perl module and a perl-based solution called Apache::ASP. This is not as clean of a solution as others, so do a lot of research before you decide on this free solution.

If you decide to scrap your IIS --> Apache project, one major reason will likely be dealing with ASP or .NET Framework applications that run great under IIS.

Learn a new management style

If you're an IIS guru, the Internet Services Manager has probably become a familiar tool for you. In IIS 6.0, the Internet Services Manager manipulates the XML-based IIS metabase. What Apache administrators have been able to enjoy for a very long time is the manipulation of server configuration files using nothing more than a text editor. While this is possible in IIS 6.0, it's far from a well-known fact! In versions of IIS prior to IIS 6.0, the metabase was a binary file that required special tools to manipulate.

Apache, on the other hand, uses simple, (usually) readable, plain-text configuration files to handle 100 percent of its configuration. When you need to change the path of your server's document root file, you just load up httpd.conf (Apache's main configuration file) into a text editor, look for the DocumentRoot directive and change the path.

It's a big plus that you don't need any special tools to make configuration changes to your Web server. GUI-based tools, at times, can make the reconfiguration job more difficult.

Second, for a production Web server, the corruption of a single file should not result in an unusable Web server. While you always need to back up configuration files, it's easier to back up the contents of a text-based configuration file in multiple places. For example, for Apache, you can print the contents of your httpd.conf file after you make changes.

On the flip side of the complexity equation, if you do like Apache's text-based approach, you'd be prudent to install some kind of versioning system so that you can easily track changes made to these files. That's one thing you don't really have to contend with under Windows, since it's a little harder to make mistakes that bring the system down that you have trouble finding later on.

Note: The upcoming IIS 7.0 (coming with Windows Server 2008) will drastically change the way IIS is managed, and will support text-based configuration files, a la Apache. The jury is still out on how successful this endeavor will be, but we'll all find out soon after Windows Server 2008 is released.

Of course, Windows admins are very used to GUI-based management tools, so converting to a text-based approach may require some time and training. Make sure to allow yourself enough time to become familiar with Apache's various directives and commands.

Go modular

There's a module for PHP, a module for Perl, a module for MySQL, a module for this and a module for that. Simply put, Apache is nothing if not incredibly modular. The Apache approach is this: Install only what you need and nothing else. This seriously reduces the attack surface of the Web server and also improves performance. Yes, you can disable certain IIS services, particularly under IIS 6.0, but a default IIS 6.0 installation is still less efficient -- and more prone to attack -- than a default Apache installation.

What do you need to learn here? First off, everything in Apache is handled through some kind of module. Want database access, scripting, or proxy services? Get a module. This is definitely a good way to handle this kind of service, but Windows administrators may not be used to the flexibility offered by a system like Apache. There are hundreds of modules available that help you make Apache do new and interesting things.

For example, with IIS, you're somewhat limited with your authentication methods. With Apache, as of this writing, there were 74 modules listed on the Apache Module Registry that are all designed to extend Apache's authentication methods to other systems, including PostgreSQL databases, IMAP servers, LDAP directories, NT servers, Oracle databases, and a whole lot more.

In total, the Apache Module Registry has well over 400 modules, all designed to help Apache help you meet your goals.

This brings up the issue of how you handle direct connections to things like Microsoft SQL Server, which is commonly used with IIS. An open source implementation called FreeTDS provides your Linux or IIS-less Windows Server with the capability to continue to communication directly with SQL (or Sybase) servers.

Or, while you migrate from IIS, you could also consider migrating to a lower cost database such as MySQL or PostgreSQL.

Note: IIS 7.0 is also supposed to "go modular," a la Apache.

As for other modules, such as IIS-specific ISAPI modules, you will need to migrate these to something that works outside of IIS, such as NSAPI. Apache does include the mod_isapi module, which provides basic ISAPI extensions, but not support for ISAPI filters.

Understand platform differences

Default.htm vs. index.html. The difference is subtle, but will bite you if you don't notice it. Apache's default document is "index.html" whereas IIS uses "default.htm". Further, Windows systems use path names with backslashes, while Linux and UNIX use normal slashes.

As you migrate your site, make sure to be aware of platform differences and adjust appropriately. I would recommend adding another default document named "index.htm" to your Apache configuration file and also allow Apache to process files with both ".htm" and ".html" extensions.

The birds-eye steps

The migration from IIS to Apache is not trivial, but it can be broken down into just a few high-level decision-making steps.

Decide on a platform

The good news: Apache runs on practically anything you have. Run it on Windows, Linux, UNIX, or NetWare, and it will work.

The bad news: This makes your decision about where to run Apache a little more difficult.

After all, with IIS, your platform decision was made for you. With Apache, you're free to choose to run Apache anywhere you like. The answer to this question lies in your overall environment. If you're open to trying open source in your environment, or you're trying to move to open source, consider Linux. If you're only moving away from IIS for security reasons, consider sticking with Windows.

Decide the future for scripting in your organization

If your IIS servers use ASP, I recommend you try Sun's ASP server product. It does a surprisingly good job at working with your ASP code on any platform. However, be wary, since Sun may not be taking development of this platform seriously, particularly since they've indicated that version 4.0.3 is slated for release in late 2007. Version 4 was announced two or three years ago.

If you're not doing any scripting yet and are serving just static pages, this point is moot; but if you do, look for something pervasive, like Java or PHP.

Choose your database

While there is no reason to move off SQL Server, if you're in an organization committed to moving off closed-source products, consider the use of MySQL or PostgreSQL for your database needs. I've used PostgreSQL for some significant databases and have directly migrated SQL Server databases to the product, and have found it to be a very worthy replacement.

Find modules

Does your IIS server authenticate users against Active Directory? You'll need Apache's mod_ldap. Go through your entire site and ask yourself exactly how it works, and locate the Apache modules that you will need to support your business.

Install, migrate and test!

Once you've made all of your selections, install your new servers, install the supporting services, such as Apache modules or Sun ASP, migrate your code, and test it thoroughly.

Summary

As you would expect, any conversion like this can't be broken down into two or three steps and called good, except for the simplest of sites. Decide if it's worth taking the plunge, and then plan your strategy very well. With Apache's wealth of support resources, you will probably be able to conquer any problem that comes your way.