| download source code Migration to IIS 6 can present itself as a daunting challenge. Depending on your existing
hosting configuration, the process can number in hours, days, or even weeks. Careful
planning and research is integral to achieve a successful migration. Recently I implemented an IIS 6 migration in my organization. During the initial research
phase I found scattered information across different Internet resources and noticed that
many organizations that still have not made the move. Shocking as that might seem, there
are plenty of you this boat. My hope is to provide you with the information you'll need
to help steer you in the right direction. Overall, I will address migration to IIS 6 from IIS 5 and issues you will encounter
with applications and hosting configurations. I will also provide details concerning
data synchronization, permissions, IIS settings, and other administrative tasks. If you
don't load balance your website already, it is a perfect time to start 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.
Initial Specs My company hosts over 100 websites across multiple shared servers running Win2k/IIS5.
Prior to the IIS 6 transition, none were load balanced. A majority of the websites use
basic ASP, while others consist of static HTML and newer ASP.Net websites. In addition,
portions of the websites use session/application variables. Of these websites, 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 website 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,
your session based applications can continue to work normally, albeit only for the set
affinity. If you do not use sticky sessions your 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.
Data Synchronization 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.
In my case, 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 website content (e.g.
e:\inetpub\sites\) - 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 website. From IIS Manager on PRODIIS1, you
create the website 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:\windows\system32\iiscnfg.vbs /s IIS1 /copy /ts PRODIIS2
cscript replace_text_in_file.vbs //nologo "172.7.1" "172.7.2" "\\PRODIIS2\c$\windows\system32\inetsrv\metabase.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 website ends with the same mask. So
if your web farm consisted of five websites with two servers, the IP's would be allocated
as demonstrated in the table below. | Website | PRODIIS1 IP | PRODIIS2 IP | | www.domain1.com | 172.7.1.1 | 172.7.2.1 | | www.domain2.com | 172.7.1.2 | 172.7.2.2 | | www.domain3.com | 172.7.1.3 | 172.7.2.3 | | www.domain4.com | 172.7.1.4 | 172.7.2.4 | | www.domain5.com | 172.7.1.5 | 172.7.2.5 |
Note: PRODIIS1 and PRODIIS2 belong to the 172.7.x.y subnet where x is assigned to the server and y denotes a common website digit. This configuration would support up to 255 websites 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.
SMTP and FTP There are a few subtle issues involving SMTP and FTP services, such as the absence of CDONTS. Your e-mail
form may choke if you don't take one simple measure: copy cdonts.dll from a Win2k machine (located in system32)
and copy to the system32 directory. Or, if you're feeling a bit more daring, you can convert all the CDONTS
calls to CDO which is a good option depending on the amount of calls used. I would caution against the second
method if you're in a hosting situation where your clients expect CDONTS functionality. For SMTP management, you should consider replacing references to the system partition (usually c:\inetpub\mailroot) and place on your data drive. Do this by opening up the metabase file and do a search/replace. You will want to copy the directory structure as well. FTP services aren't much different than in IIS 5 except for the new feature for isolated FTP sites. Be certain you use the option "Do not isolate users". Otherwise you'll generate a "Home directory inaccessible" error message when logging into the site.
IIS 5 to IIS 6 Migration Physically moving websites from server to server can vary greatly between organizations. Consequently, it's difficult to detail every step. Most migrations involve three main areas: IIS settings, data, and intangibles. The first two areas are straight forward while the last deals with any specialized setting/service that may also need to run on the new servers. This could encompass anything from COM components to custom Windows services. Depending on the number of websites and their inherent application setting complexities, you will have to
decide on moving IIS settings manually or in an automated fashion. "Manually" is characterized
simply by recreating the website(s) in IIS manager with the possibility of referencing a metabase dump
(check out absutil.vbs). The automated route involves using a tool like the IIS 6 Migration tool
(download here).
You may even take it a step further and write a batch utility to move all the websites at once. An automated, single website migration is detailed as follows. The IIS 6 migration tool (IISMT) allows you to migrate a website from an IIS 5 server to IIS 6. This command-line tool runs off the destination IIS 6 machine. If you take a peek at documentation associated with the download, you'll notice a number of options. Most significant are the options for: - "Website/W3SVC" - Name of site identifier of old source website
- server_binding - String containing new IP address, port, host header (e.g. 172.7.1.1:80: )
- site_id - Usually a random 9 or 10 digit number (can use http://www.winguides.com/security/password.php to generate ID). If created in IIS, the site ID is fashioned after the name of the website (IIS 6 no longer uses auto identifiers as a security precaution)
- configonly - Moves only IIS settings, not website data
Running IISMT while moving data is the default behavior, but I found that it also moves ACL's as well. Although this can be desirable, local groups are moved which can result in broken SID's on the destination machine. If this applies to you, opt to move data by a simple xcopy: xcopy \\target\e$\inetpub\sites\domain.com e:\inetpub\sites\domain.com /E /H /Y
Alternatively, the Microsoft SubInAcl command-line tool can work to replace/delete SID's. Or even a more power utility SetACL (available at http://setacl.sourceforge.net). This tool is superior to CACLS/XCACLS and doesn't suffer from the inheritance bug (http://support.microsoft.com/?id=834721)
Putting It All Together Now that I've described some of the concepts and tools required of a load balanced environment, let's expound upon the earlier example of hosting five websites. Imagine they currently reside on a single, shared IIS 5 server and need to be moved. The following table lists the fake source website information: | Domain | W3SVC # | IP Address | Document Root | | www.domain1.com | 1 | 172.6.1.1 | e:\inetpub\sites\www.domain1.com\wwwroot | | www.domain2.com | 2 | 172.6.1.2 | e:\inetpub\sites\www.domain2.com\wwwroot | | www.domain3.com | 3 | 172.6.1.3 | e:\inetpub\sites\www.domain3.com\wwwroot | | www.domain4.com | 4 | 172.6.1.4 | e:\inetpub\sites\www.domain4.com\wwwroot | | www.domain5.com | 5 | 172.6.1.5 | e:\inetpub\sites\www.domain5.com\wwwroot |
OLDIIS - Host info With this information in hand, it's time to start moving IIS settings and data! Start by logging into the primary IIS 6 server (PRODIIS1 in this example). Now follow these steps for each site, substituting the correct source and destination info (www.domain1.com used below) iismt OLDIIS w3svc/1 /path "e:\inetpub\sites\domain1.com\wwwroot" /serverbindings 172.6.1.1:80: /siteid 842798180 /overwrite /configonly
* Make sure /siteid value is unique for each website. To generate ID use link provided earlier Copy data off target server like so: xcopy \\OLDIIS\e$\inetpub\sites\domain1.com e:\inetpub\sites\domain1.com /E /H /Y
Run IIS sync batch command from PRODIIS1 Set any ACL's if need be on all servers in web farm. I would recommend creating another batch file to ACL common routines such as setting basic authentication. I've provided such a sample in the article download.
Conclusion Finally, I want to provide a list of assorted tips as they relate to load balancing and IIS 6. - Use standard internal IP naming conventions
- Increase upload limit for ASP application by setting the property AspMaxRequestEntityAllowed in the IIS metabase. Default value is a measly 200k
- In IIS manager under the configuration button, enable parent paths so your SSI calls work with relative pathing
- If you use a local IUSR account for anonymous users, rename it so that it isn't machine specific (e.g. IUSR_PRODUCTION instead of IUSR_PRODIIS1). Same goes for the IWAM account
- Ensure that your machine.config files on each server match
- Create a static machineKey element in the machine.config file. Refer to KB article (http://support.microsoft.com/default.aspx?scid=kb;en-us;Q312906) to create validation and decryption keys
- If you encounter an ASP.net error saying something like "Access denied to 'E:\inetpub\sites\domain1.com\wwwroot\admin\web.config'. Failed to start monitoring file changes". Add the "NT AUTHORITY\NETWORK SERVICE" account to the directory in question
- Files that are writable by an application should be placed in separate directory so that permissions can be granted on the directory rather than individual files. Otherwise the data synchronization service will wipe out ACL information
- Create separate application pools for websites with direct FTP access or those have they extensive programming. Logically name these pools too (e.g. app.domain1.com)
I am confident that if you engage with the tools and recommendations provided, you will experience an equally rewarding and beneficial transition to IIS 6. Happy Migrating!
About the Author Gregg Faus, MCAD.Net, is a Senior Web Software Engineer for Company 39 / Parsons Brinckerhoff.
He works with a breadth of technologies including ASP.Net, C#, SQL Server, Flash, and Content
Management Systems using Interwoven. Contact him at gregg.faus@yahoo.com.
|
