Migrating to IIS 6 can be a daunting process. Depending on your existing hosting configuration, the process can take hours, days, or even weeks. Careful planning and research is integral to a successful migration.
Migration to IIS 6 can be daunting. Depending on your hosting configuration, the process can take weeks. With careful planning and research, a successful migration is more easily achieved.
This article will address migration to IIS 6 from IIS 5 and issues you may encounter with applications and hosting configurations. Details about data synchronization, permissions, IIS settings, and other administrative tasks will also be provided. If your Web site is not already load balanced, now is a perfect time to do it because you’ll already be moving settings and files anyway, not to mention the availability and scalability benefits. Glean what information you need as it applies to your scenario.
My company hosts more than100 Web sites across multiple shared servers running Win2k/IIS5. Prior to the IIS 6 transition, none were load balanced. A majority of the Web sites use basic ASP, while others consist of static HTML and newer ASP.Net Web sites. In addition, portions of the Web sites use session/application variables. Of these Web sites, most use a local instance of SMTP server, and a few have FTP access.
The basic requirement of load balancing requires at least two servers. Therefore, two dual-processor Win2k3 servers (Web Edition), each with ample disk space, are used. Our Web site content is currently stored locally. Utilizing a NAS solution would alleviate file replication issues (detailed later in this article). Load balancing is done via a network device (BIG-IP) configured to run in a “Round Robin” fashion with session affinity set to 10 minutes (a.k.a. sticky sessions). By using sticky sessions, session-based applications can continue to work normally, albeit only for the set affinity. If you do not use sticky sessions, session or application data may be lost from request to request.
A normal Win2k3 build was performed on our server build out; however, only the application server role was specified and ASP.Net/FTP services enabled. A separate partition was also used to isolate all Web server related activities, including content, log files, COM components, and SMTP service files. Previous to IIS 6, this was not as easy.
From a load balancing perspective, synchronizing data across servers in the Web farm is extremely important so that users see the same data, regardless of which server services the request. There are many products to choose from in this regard. Products like Microsoft DFS, robocopy, and other third-party solutions can make it hard to decide. I needed real-time synchronization capabilities, which robocopy couldn’t provide, and DFS seemed excessive. After reviewing many of the third-party solutions, I chose PeerSync from Peersoft. PeerSync installs as a service, syncs files instantly (services can “listen” on OS level files changes), and can exclude certain directories and open files. Although I support this product, it is expensive. The heavy feature set went mostly unused, however the performance and reliability of the service is excellent given the amount of data to be synchronized.
I configured the product in the following way:
- Multiple machine real-time setup (refer to support documentation for additional information)
- Synchronized only the Web site content (e.g.
- Excluded directory “/catalog.wci” and temporary files created by our deployment software
IIS 6 Metabase
The move to IIS 6 makes replicating configurations across multiple servers much easier. Formerly, the metabase was stored in a binary format not easily editable. Now configs are stored in a XML format that can be copied from server to server (with small changes). This can save vast amounts of time when managing a server in your Web farm. Although products such as MS Application server can be helpful, you can opt for the poor man’s solution. This involves using one server (could be any in the farm) to manage IIS settings and then use the command-line tools that come with IIS to create a batch file to sync the metabase across the other servers.
For example, if you have two servers in your web farm (PRODIIS1 & PRODIIS2) and a new request requiring you to create a new Web site. From IIS Manager on PRODIIS1, you create the Web site but how do you get the settings over to PRODIIS2 without recreating the same settings? Create a batch file with the following commands:
cscript c:windowssystem32iiscnfg.vbs /s IIS1 /copy /ts PRODIIS2
cscript replace_text_in_file.vbs //nologo "172.7.1" "172.7.2" "PRODIIS2c$windowssystem32inetsrvmetabase.xml"
The first line executes the IIS 6 CLT to export the “PRODIIS1” metabase file to “PRODIIS2”. It removes any machine specific settings in the process. However, since IP addresses are going to be machine specific you will have to handle this case accordingly. I would recommend using a standard IP naming convention where each server is subnetted in a way that every server replicated Web site ends with the same mask. So if your web farm consisted of five Web sites with two servers, the IP’s would be allocated as demonstrated in the table below.
Note: PRODIIS1 and PRODIIS2 belong to the 172.7.x.y subnet where x is assigned to the server and y denotes a common Web site digit.
This configuration would support up to 255 Web sites, which is adequate for a typical shop. Additionally, it will make your network administrator happy when it comes time to configure the load balancer.
Looking at the batch script again, line two uses the knowledge of your IP naming convention to replace the IP addresses synchorized from “PRODIIS1” to those belonging to “PRODIIS2”. The script “replace_text_in_file.vbs” is provided in the article download.
>> The Upgrade
This article was originally published on 15 Seconds.